Howard Chu wrote, On 2008-08-17 22:21: > 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.
Whoa, you think of libraries as users? I think you're saying that you expect every library to have its own set of trusted certs, as if libraries -- and not true human users -- get to decide what certs are trusted and what are not. A human user doesn't need a separate store of certs for every one of his libraries or applications. The notion that code, and not the user, makes the security decisions about what is trusted and what is not trusted, is the basis of many vulnerabilities. > 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. NSS_Shutdown is a known issue. > 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. Sounds like you really believe that the libraries, and not the user, should be in control of what is trusted and what is not. If libraries are changing the user's set of trusted certs without the user's consent, then all manner of problems (vulnerabilities) will arise. > The API design is flawed and cannot be easily fixed; a full and complete > fix would require an incompatible API change. We've already seen that the NSS_Shutdown issue can be solved without any API *change*, but through the mere addition of a new function to the API. > 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. The thing that is being held up as the model to which we should aspire uses a single common system-wide directory of trusted certs, e.g. /etc/ssl/certs, or a per-LIBRARY (but nonetheless system wide) directory of trusted certs, e.g /etc/openldap/ssl/. That's not the model we want going forward. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
