When PKCS#11 tokens are configured in the system's p11-kit, they should be automatically visible to applications. NSS should be automatically loading the appropriate modules at nss_Init() time in most cases... except possibly NSS_NoDB_Init)( perhaps? It's also been suggested that we automatically configure the databases in /etc/pki/nssdb and sql:/etc/pki/nssdb to reference p11-kit-proxy.so but that's only useful if we also fix NSS applications to actually *use* those databases. Currently the major applications (Chrome, Firefox, Thunderbird, etc.) don't. Perhaps the best option is for the nsssoftokn to gain a NSS_ReturnModuleSpecData() entry point, which will enumerate the modules configured by p11-kit and cause them to be loaded?
In the short term it would be useful to know what applications should be doing if they *care* about being well-behaved. Can they start using SECMOD_LoadUserModule(p11-kit-proxy.so) for themselves, and if so should they make it conditional on something so that they don't continue to do that once NSS has a *proper* fix?
Oh, one other hack that works surprisingly well in the short term is just symlinking libnssckbi.so to p11-kit-proxy.so instead of p11-kit-trust.so So any application which wants the trust roots will *also* pull in the default PKCS#11 tokens. It's only the applications *without* the trust roots that don't.
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
I think we can resolve this in crypto-policies, given the observation in https://bugzilla.redhat.com/show_bug.cgi?id=1157720#c66
... and a small patch to *fix* the crypto-policy loading, filed upstream as https://bugzilla.mozilla.org/show_bug.cgi?id=1296263 Now I can add library=p11-kit-proxy.so to the 'nss.txt' crypto policy, and things seem to work as expected.
While setting that into crypto policies makes things work, crypto-policies is the wrong component to address that issue. This component is only about ciphers, protocols and their priority. Adding that fix seems like a non-rational action. If however, we provide a way for generated crypto policies to be amended and the NSS maintainers agree, the nss package could amend the generated policy to add non-policy specific items.
(In reply to Nikos Mavrogiannopoulos from comment #6) > While setting that into crypto policies makes things work, crypto-policies > is the wrong component to address that issue. This component is only about > ciphers, protocols and their priority. Is it? Where is that definition written down? Using the correct PKCS#11 modules is Fedora system policy; it's written in the packaging guidelines. From the point of view of the NSS package and upstream, it seems that the system policy file is *precisely* the right place to implement such policies. It was even explicitly referenced in Bob's comment at https://bugzilla.redhat.com/show_bug.cgi?id=1157720#c13 where he said "You can also force loading other PKCS #11 modules (like trust stores) with this, but remember that this affects *ALL* nss programs" > Adding that fix seems like a non-rational action. If however, we provide a way > for generated crypto policies to be amended and the NSS maintainers agree, the > nss package could amend the generated policy to add non-policy specific items. There is a mass of subjectivity here. All we need to do to make it seem rational, is think of the "crypto policies" package as "system policy for crypto libraries". We wouldn't even need to change the name — just expand our understanding of its scope to cover what it can *already* technically do. To be honest, I don't actually care *how* we do this or how we justify the minutiæ of the terminology we use. But please, let's make this *work* ASAP. We have the pieces in place to make NSS-using applications conform to Fedora packaging guidelines, right now — they can use the right PKCS#11 providers, and we can reference objects by PKCS#11 URI. All we need to do is merge the patches in the outstanding NSS reviews, and sort out the Fedora system policy. We ought to be able to do that for Fedora 25; it would be a shame if it had to wait for Fedora 26. And a travesty if we didn't even manage it for F26.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
Pushed the relevant changes to nss: https://src.fedoraproject.org/rpms/nss/c/6f4f615c051ed6204a08973fe13046c05da5cf20?branch=master