IMO, this is not an NSS issue, it is rather a *NIX issue. All other operating systems (that I'm aware of NB...) including *NIX-derivates like Android, already have a system-wide cryptographic architecture.
Most (if not all) of these builds on services rather than libraries. Anders On 2012-07-24 15:07, David Woodhouse wrote: > Is the NSS "shared system database" actually going to be used for real? > I note Firefox *still* isn't using it, four years after bug 449498 was > opened. > > If even Mozilla products aren't using NSS "properly", do we really > expect anyone *else* to? > > And what does "properly" mean, anyway? As far as I can tell, the only > way an application can *tell* whether the shared database is set up on > the system is to open /etc/pki/nssdb/pkcs11.txt and search for > 'library=libnsssysinit.so' in it. Based on the result of that search, > the application then opens sql:/etc/pki/nssdb or sql:$HOME/.pki/nssdb. > Which is just evil. > > It seems that the shared system database isn't really complete, and > isn't particularly well-thought-out. Is there scope for changing it? > > For example, is there a reason that things weren't done the other way > round? Why couldn't the softokn module just automatically load the > contents of /etc/pki/nssdb as an extra read-only slot, regardless of > which directory the application gave as its primary store? Surely that > would have been easier? > > I've also been looking at how to consolidate the trust database with > other SSL libraries, such as OpenSSL and GnuTLS. GnuTLS can load the NSS > softokn as a PKCS#11 module, and access *one* database, although there's > a bit of work to be done on understanding the trust assertions. But I > can't see how to get the softokn module loaded from p11-kit with *both* > slots available. Is that possible? > > Again, if we switch things around so that you just load > sql:/$HOME/.pki/nssdb and the additional slot is automatically loaded > from /etc/pki/nssdb *if* a database exists there, this may all "just > work"... is that something we can consider? > > > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
