1161219 - Load system-configured PKCS#11 tokens by default

Status: RESOLVED DUPLICATE of bug 248722

(NSS :: Libraries, defect)

Description

[David Woodhouse]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150421074559

Steps to reproduce:

I installed the OpenSC package on my Linux system, which provides a PKCS#11 module for using a smart card (in my case a Yubikey NEO).


Actual results:

The distribution packaging installed a file in /usr/share/p11-kit/modules/opensc.module which caused its PKCS#11 provider to be automatically visible in all well-behaved applications.

I could immediately use the certificates in my token, for example in the OpenConnect VPN client by referencing them with their standard RFC7512 URI:
 'openconnect -c "pkcs11:manufacturer=piv_II;id=%01"'

I was not able to use the device with applications which used NSS. I had to create a NSS DB and manually add the token (or p11-kit-proxy.so) to that DB with 'modutil', before the token was visible. As described for example at https://bugzilla.redhat.com/1217727#c1


Expected results:

Any token present in the system's p11-kit configuration should be visible to NSS applications as intended.

Comment 1

[David Woodhouse]

I was able to work around this issue for most use cases by creating a symlink from libnssckbi.so to p11-kit-proxy.so (instead of the normal symlink to p11-kit-trust.so). That makes the system-configured tokens get loaded automatically. It isn't quite the right fix though.

Comment 2

[Ryan Sleevi]

p11-kit is a project independent from NSS. Why should it be expected that NSS uses it?

Comment 3

[David Woodhouse]

This isn't about 'p11-kit' per se.

This is about integration with the platform that NSS is running on — using the PKCS#11 tokens which are installed with that platform's packaging, and registered with that platform's mechanism for managing PKCS#11 providers.

In modern Linux distributions, the mechanism in question *happens* to be p11-kit. NSS is expected to integrate correctly with the system, which on those platforms means using the p11-kit configuration — which is easy enough to do just by loading p11-kit-proxy.so if it's available. You can even use pkgconfig to detect whether it's available and where it is:

 $ pkg-config --variable=proxy_module p11-kit-1
/usr/lib64/p11-kit-proxy.so

Comment 4

[David Woodhouse]

Perhaps this is a duplicate of bug 248722, filed 11 years ago before p11-kit existed.

Comment 5

[Ryan Sleevi]

Is it fair to say "modern Linux distributions use p11-kit"? Is it part of the LSB? Is it part of any other system other than Fedora-and-derived? Is it the default installed system?

I don't believe so for any of these, but I'd be happy to have more information. I think you need to provide stronger justification for why than "because" or "because I'll fork apps to not use NSS if you don't"

Comment 6

[David Woodhouse]

As noted on the mailing list, I'm not aware of any modern desktop Linux distribution where the p11-kit package isn't such a *fundamental* dependency that it's impossible to remove it without removing most or all of the rest of the distro.

Fedora is just the first to have explicit written guidelines that all packages SHOULD load the tokens configured in p11-kit. For all the other distributions (including *BSD and Solaris where p11-kit is present), it remains purely a good idea and not a written guideline.

Basically, if $(pkg-config --variable=proxy_module p11-kit-1) on your system returns a value, it's kind of silly *not* to load that module as one of the PKCS#11 tokens. Perhaps a short-term fix could be as simple as making the softokn's Module DB transparently add that?