Fixing NSS and p11-kit in Fedora (and beyond)

David Woodhouse dwmw2 at
Fri Dec 12 01:48:41 PST 2014

On Fri, 2014-12-12 at 09:22 +0100, Stef Walter wrote:
> On 11.12.2014 10:12, David Woodhouse wrote:
> > I'd love to have a Fedora Feature in F22 for PKCS#11, where keys+certs
> > from installed PKCS#11 modules are expected to Just Work™ in all
> > applications that can use certificates. Using consistent PKCS#11 URIs
> > where appropriate. Even if we aren't ready for a Feature, I'd love to
> > make some more progress in that direction. Obviously none of this is
> > really Fedora-specific, but if we can get it right in Fedora (as we did
> > for the trust stuff), other distributions can follow.
> I believe there's an open process for proposing Fedora Features and I
> think it's going on right now. But I agree that doing all of this in a
> few months is a bit much to bite off, even for someone as tireless as
> you :D

Yeah. I'm severely tempted at least to file an overall tracker bug for
the "feature", and file individual bugs against all the packages that
need to be "fixed" to comply with the vision. It'll make it much easier
to track. Any objections?

> Note that /etc/pki/nssdb is also not completely safe on multi-user
> systems. One user can easily lock the database and prevent any other
> user from doing NSS crypto with that database. Correct me if I'm wrong.

Bob knows best, but I'm not sure I recognise that problem. The database
in /etc/pki/nssdb is read-only, so I don't think unprivileged users can
do *anything* to screw with others' access to it.

Perhaps you're thinking of the database in ~/.pki/nssdb which is shared
between various applications belonging to the same user. There probably
*is* a potential for apps to interfere with each other there, but only
*one* user's apps so it's not such an issue.

> <snip>
> >  - Modify NSS to automatically load p11-kit modules.
> > 
> > Maybe slightly saner than hacking the apps, we could make NSS
> > automatically load (-trust) whenever the database is
> > initialised. Or even better, perhaps it could use p11-kit and
> > p11_kit_modules_load() directly instead of
> Not sure this solves the actual problem (given that NSS apps do not use
> a consistent database location) but NSS actually can ask a PKCS#11
> module if it wants to load more modules.
> NSS_ReturnModuleSpecData()
> I believe this is undocumented. But Bob has mentioned it as something
> that p11-kit should be doing in order to tell NSS about which other
> PKCS#11 modules to load.

Right. I currently have this hack which works OK, but I'm still a little
clueless about that *right* place (and circumstances under which) to do
this. The nss_Init() function has a plethora of flags which I'm not
entirely sure I understand.

--- nss/lib/nss/nssinit.c~	2014-10-10 17:56:55.000000000 +0100
+++ nss/lib/nss/nssinit.c	2014-12-11 16:26:58.113699892 +0000
@@ -435,7 +435,14 @@ loser:
 	SECMODModule *module = SECMOD_LoadModule(moduleSpec,NULL,PR_TRUE);
 	if (module) {
-	    if (module->loaded) rv=SECSuccess;
+	    if (module->loaded) {
+		    SECMODModule *mod2 = SECMOD_LoadModule("library=/usr/lib64/ nss",module,PR_FALSE);
+		    if (mod2) {
+			    printf("Loaded\n");
+			    SECMOD_DestroyModule(mod2);
+		    }
+		    rv=SECSuccess;
+	    }

Since I think this code in nss_InitModules() will (almost?) always be
loading, perhaps the better answer is for the p11-kit
integration to live there — implement a NSS_ReturnModuleSpecData()
function in which does the p11-kit enumeration and
returns the list of additional modules to be loaded.

(Although actually using did have the advantage that
then the submodules were loaded through p11-kit instead of NSS's own
SECMOD code, which means that coordination of multiply-loaded modules
would work nicely. But maybe we should work on the SECMOD code

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <>

More information about the p11-glue mailing list