On Mon, 2014-12-08 at 13:56 -0800, Robert Relyea wrote: > On 12/08/2014 08:59 AM, David Woodhouse wrote: > > I still maintain that the path to sanity involves killing > > /etc/pki/nssdb entirely, and then you can look at applying *correct* > > fixes to whatever's still not behaving correctly. > > The whole point of /etc/pki/nssdb is so you have one place to install > stuff.
Well, kind of. Except that for system-trusted CAs, there is *already* "one place" to install stuff. That's libnssckbi.so. And with the native NSS version of that library dropped, and a symlink in place to p11-kit-trust.so, we have this working *properly* in line with the sysadmin's choices for which CAs to trust. As you reminded me, applications choose to open libnssckbi.so *if* they want the system trust. So it's important that we have "one place" for it. The Shared System Database approach, with *some* CAs in libnssckbi.so and *some* installed by the sysadmin into sql:/etc/pki/nssdb means that the application's *choice* of whether to load the trusted CAs is confused. If they choose *not* to load libnssckbi.so they might get *some* trusted CAs from sql:/etc/pki/nssdb anyway. And for additional PKCS#11 modules there's *already* "one place" for those too. If I install the OpenSC package, it'll automatically drop a file into /usr/share/p11-kit/modules/ and well-behaved applications will automatically see it. We just need to make NSS applications behave well — and yes, adding p11-kit-proxy.so to /etc/pki/nssdb/pkcs11.txt *might* be part of the approach there. Although you don't want the trust modules in that case, since *those* come through the libnssckbi.so symlink to p11-kit-trust.so. > It's the default for anything that I've had a say in and will > continue to be the default. That's OK. We just need to work out how to make it *work* :) -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
