Nelson B Bolyard wrote: > Previously, someone criticized NSS, saying that it was designed for use > only on single-user systems, a criticism that I dispute. NSS is very much > oriented toward each user have his own set of trusted flags. In contrast to > NSS, the idea that there is only one system-wide set of trusted certs, > and that each user does not have his own set, is a very single-user-system > approach.
It seems you misunderstood my previous criticism, so I'll try again. I said NSS is obviously designed for a single-user *environment*, and doesn't cope well at all when multiple NSS users exist in a single process. By "users" I meant "users of the API", i.e. callers. This thread is yet another perfect illustration proving my point. If multiple libraries are loaded into a process that all use NSS, only the first piece of code that calls NSS_Init gets its settings loaded. If any of them calls NSS_Shutdown then NSS is torn down for the entire process, no matter how many other pieces of code were relying on it. The fact that each caller within a process cannot isolate its settings into its own context makes it unsafe for use in these environments. The fact that one caller's use of certain API calls can pull the rug out from under other callers makes it unsafe for these environments. The API design is flawed and cannot be easily fixed; a full and complete fix would require an incompatible API change. I suggested an approach in my previous post in this thread, but while it maintains a measure of compatibility it's still not fool-proof. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
