On 12/04/2014 03:31 AM, David Woodhouse wrote:
Huh? that is not true. libnssckbi.so is loaded by nssysinit, or by the application or by someone explicitly loading it into the pkcs11.txt/secmod.db. It is not loaded automatically by every nss application.You say that this shouldn't be necessary (and probably a bug), just to clarify things for me, do you mean that, 1 ) "adding the libnssckbi.so to shouldn't be necessary since it should already be there from the beginning, and that the bug is that the library is missing from the default setup", orThat one. libnssckbi.so is what provides the default trust roots. It's *always* supposed to be loaded in an NSS system. You shouldn't need to add it manually. I don't.
I believe the p11-kit does some magic to get it loaded for mozilla and the root store. Kai worked with stef to get that working, kai do you recall how that hooks in?
bob
(Note that you also shouldn't need to add your CAs to the actual sqlite database in /etc/pki/nssdb either, since they should be coming from your "libnssckbi.so" which is actually p11-kit.)Now the libp11-proxy,I worked around it by symlinking /usr/lib64/libnssckbi.so to p11-kit-proxy.so instead of p11-kit-trust.so, which gives me the trust roots *and* the other loaded modules. That one probably ought to be the default.Ok, I did the same thing. Using the alternatives system.Firefox only asks me to log into my p11-kit-provided hardware tokenswhen I go to a web site which wants a certificate, which is fair enough.Yes, same behavior here, I was mistaken when I stated that it actually asked for pins to GNOME keyring and the Secret Store. Firefox behaves in my opinion as expected, and I don't need to "manually mess" with the users nssdb - the default will just work as I expect (trusting my CA and ask for PIN to hardware token when requested).Did you have to manually add libnssckbi to Firefox too? Remember, that uses its own database and not sql:/etc/pki/nssdb.Evolution does ask for a PIN for GNOME keyring and the Secret Store. Stef suggests that's because Evolution doesn't handle CKF_PROTECTED_AUTHENTICATION_PATH. I filed this bug for that: https://bugzilla.gnome.org/show_bug.cgi?id=741059Cool, then we have the same behavior and a possible reason for why it behaves like it does. The same thing goes for chrome, I'll file a bug-report to those ppl referring to this bug.Chrome uses sql:$HOME/.pki/nssdb and not sql:/etc/pki/nssdb. Did you add libnssckbi.so to *that* one? (Evolution will use sql:/etc/pki/nssdb *if* it's enabled, and sql:$HOME/.pki/nssdb if not. A piece of horridness fundamental to the "design" of the NSS Shared System Database.)breaks pam_pkcs11. Using the above config, pkcs11_inspect throws the following, ... DEBUG:pkcs11_lib.c:272: loading Module explictly, moduleSpec=<library="/usr/lib64/pkcs11/opensc-pkcs11.so" name="SmartCard"> module=/usr/lib64/pkcs11/opensc-pkcs11.so DEBUG:pkcs11_lib.c:276: Failed to load SmartCard software (null) ERROR:pkcs11_inspect.c:73: load_pkcs11_module(/usr/lib64/pkcs11/opensc-pkcs11.so) failed: Not really sure why this happens, but changing the lines,I suspect this is because it's trying to explicitly load opensc-pkcs11.so when it was *already* loaded. I wonder if works better if you point it at p11-kit-proxy.so instead. Not sure if that can cope better with multiple initialisations, if such a thing is even possible. Further discussion of that might be more appropriately targeted to the OpenSC mailing list, since pam_pkcs11 is theirs too. In the meantime, given the bug that libnssckbi.so doesn't seem to show up for you unless explicitly requested, a potential workaround might be to point pam_pksc11 at a NSS DB which *doesn't* request it (it can request p11-kit-trust.so instead).
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
