439
edits
(Created page with ' == NSS Library Initialization == === Problem === NSS was designed as a library that a single application would use. The application would control how NSS was initialized an…') |
|||
| Line 24: | Line 24: | ||
Restrictions on any future solution: | Restrictions on any future solution: | ||
1) NSS must maintain binary compatibility. Applications should not become more broken as a result of linking with this new functionality. This means the existing shutdown should shutdown NSS in the same way that it has in the past. | 1) '''NSS must maintain binary compatibility.''' Applications should not become more broken as a result of linking with this new functionality. This means the existing shutdown should shutdown NSS in the same way that it has in the past. | ||
The existing shutdown will close down all NSS internal references to object and free up internal lists. It is possible that the application may still have NSS objects open in its address space (references to slots, keys, or certs that NSS has returned to it). NSS will shutdown all slots that do not have outstanding object references to them. If NSS cannot shutdown all slots, it will return an error. At this point NSS is 'shutdown', but it will not be able to initialized again until all those outstanding references are freed. | The existing shutdown will close down all NSS internal references to object and free up internal lists. It is possible that the application may still have NSS objects open in its address space (references to slots, keys, or certs that NSS has returned to it). NSS will shutdown all slots that do not have outstanding object references to them. If NSS cannot shutdown all slots, it will return an error. At this point NSS is 'shutdown', but it will not be able to initialized again until all those outstanding references are freed. | ||
| Line 30: | Line 30: | ||
Few applications depend on this behavior, but there are some, usually applications which have some sort of dynamic profile switching code. Even though these apps are few, they must still continue to work. | Few applications depend on this behavior, but there are some, usually applications which have some sort of dynamic profile switching code. Even though these apps are few, they must still continue to work. | ||
2) NSS still maintains a single 'trust domain' in which certificates are verified against. Internally NSS has the ability to process on independent trust domains, but the neither the creation of new trust domains, nor the passing of such trust domains to the certificate verification code is currently supported. | 2) '''NSS still maintains a single 'trust domain' in which certificates are verified against.''' Internally NSS has the ability to process on independent trust domains, but the neither the creation of new trust domains, nor the passing of such trust domains to the certificate verification code is currently supported. | ||
This feature has been a long standing 'wish list' for NSS, and has not been implemented since there has been no demand from customers. In general most uses of trust domain is better handled by the use of policies rather then different CA trees. The only use case currently identified is in virtual hosting services which services multiple customers through a single process web server. | This feature has been a long standing 'wish list' for NSS, and has not been implemented since there has been no demand from customers. In general most uses of trust domain is better handled by the use of policies rather then different CA trees. The only use case currently identified is in virtual hosting services which services multiple customers through a single process web server. | ||
== Proposal == | == Proposal == | ||
edits