On Fri, 2015-05-08 at 15:07 -0700, Ryan Sleevi wrote: > On Fri, May 8, 2015 5:38 am, David Woodhouse wrote: > > These days it does. Modern systems ship with p11-kit², which exists > > precisely to fill that gap and provide "a standard discoverable > > configuration for installed PKCS#11 modules." > > Your citation ( http://p11-glue.freedesktop.org/p11-kit.html ) fails to > support your claim that "modern systems ship it", as I've noted elsewhere.
Was it supposed to? I didn't think that observation actually needed to be "supported". I have some old Ubuntu and OpenSuSE virtual machines lying around; let's see... yes, they both have it. Now, how do I try to remove it... on Fedora, the dependencies are so fundamental that it looks like it's trying to uninstall fairly much the *whole* system if I try to remove p11-kit. SuSE is showing me this huge list of packages in a tiny 4-line window in YAST, which doesn't like like it's the *whole* distribution but it's a lot. For Ubuntu I'm not quite sure how to get the full recursive list but it's going to take out a bunch of core GNOME stuff and also anything linked against GnuTLS. I don't think the "claim" that p11-kit is ubiquitous on Linux is really a contentious one, is it? It's also present in the ports systems for various BSD systems, and used by the default build of other ports. And it's there for Solaris too. > > Although it happens to be Fedora which is first, we obviously expect > > other distributions and operating systems to follow suit â in > > practice, even if not with official packaging policy mandates. > > And of course, this note - that it's Fedora only - directly counters the > claim above that "modern systems ship" No. It's only Fedora which (so far) has package guidelines explicitly stating that its packages SHOULD consistently load the correct PKCS#11 providers according to the platform's configuration. But the others *do* ship and use p11-kit, even if they're slower to actually try to achieve *consistency* across the range of software they ship. > > Does this seem like the right approach? > > No, you should be able to do it w/o patching NSS. OK... how? If the Shared System Database wasn't such an utter failure, not even being used by Firefox itself, then just installing it there would have been a nice idea. But *nothing* used the Shared System Database, and there isn't even a coherent documented way for NSS users to discover whether they should use it or not. If calling NSS_Initialize() with a NULL configdir worked and did the right thing (sql:/etc/pki/nssdb where it's setup, or sql:$HOME/.pki/nssdb otherwise), that would be nice... but it doesn't. I do have a horrid hack that works without patching NSS. Instead of a symlink from /usr/lib64/libnssckbi.so to p11-kit-trust.so (which replaces the NSS trust roots with something that's actually obeying the system configuration), I instead symlink to p11-kit-proxy.so. That loads not only the trust roots, but *also* the other PKCS#11 providers. It works quite nicely in practice, but it isn't the *right* answer, and there are corner cases where it doesn't do the right thing. Got any other ideas? > > Under precisely what > > circumstances should we be doing it â should it be affected by the > > noModDB and noCertDB flags? > > Yes, it should. You'll introduce your users to a host of security issues > if you ignore them (especially for situations like Chrome). For example, > if you did what you propose to do, you'd be exposing people's smart card > modules to arbitrary sandboxed Chrome processes So arbitrary sandboxes Chrome processes already have free rein to use certificates in my NSS database? Isn't that a problem *already*? And if people ever want to use the PKCS#11 token in their web browser, they're going to need to expose it anyway. And if they don't, the p11-kit configuration does permit a module to be visible in some applications and not others. > As I've said elsewhere, I'm not fundamentally opposed to p11-kit, but I do > hope you can take this considerations in approach and claims into > consideration before advocating support. I appreciate you're enthusiastic, > and I'm not trying to tell you no, but I am trying to help you understand > that you're not exactly going to win advocates with the current approach. I'm happy to entertain any approach you care to suggest. The important requirement is that software across the distribution should behave *consistently*. If I have a certificate(+key) in my USB crypto token, I should be able to *consistently* use that certificate in *any* piece of software by using the *same* RFC7512 URI to identify it. -- dwmw2 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
