On Tue, 2014-12-02 at 12:00 -0500, Miloslav Trmač wrote:
> > Great. So that should solve Patrik's CA issues without needing to do
> > anything special. All that remains is to get the smartcards working by
> > loading p11-kit-proxy.so (or preferably the individual modules) too.
> >
> > Is that something we could do in the p11-kit-trust implementation of
> > libnssckbi.so without having to add another hook?
>
> That feels like an pretty icky workaround, but I don’t actually know
> whether it would or wouldn’t work. Stef, could the RHEL 6.5
> p11-kit{,-trust} be (ab)used to load a smartcard token into all NSS
> users (without changing the application-specific NSS configuration)?Well, the first question to ask would be about doing it upstream. Whether it can be backported to RHEL is a separate question for product management. (Individual users can of course do their own thing). I agree that it's a pretty icky workaround, but then again so is the current practice of simply *replacing* NSS's own implementation of libnssckbi.so with our own. But it's a neat trick which happens to work fairly nicely, and if we can extend it to *also* get the p11-kit configured modules to load at the same time without having to come up with further hacks, that would be quite nice. It also puts us in a good position to deal with the recursion that would otherwise happen when we attempt to put sql:$HOME/pki/nssdb into the user's p11-kit configuration. Doing that *and* manually configuring p11-kit-proxy into the NSS stack doesn't end well at the moment, but it should hopefully be simple to eliminate the duplicate if we do it this way. -- dwmw2
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
