Hi, alctra <[email protected]> writes:
> Hello, > > IIUC nss-certs uses certdata2pem to convert certdata.txt from nss to a > series of pems that are placed in /etc/ssl/certs and p11-kit then points > to that for its default trust store. > > However, this is limiting compared to a .p11-kit file as pems don't > carry over certificate attributes such as nss-mozilla-ca-policy. Unlike > its counterparts in other distros (see e.g. certdata2pem.py in > Debian/Arch), the certdata2pem implentation employed by Guix doesn't > parse certificate attributes into a .p11-kit file. > > Some backstory: I stumbled upon this trying to resolve #10994 by doing > what other distros did and linking p11-kit-trust.so to libnssckbi.so > (the former being a drop-in replacement for the latter) in order to make > nss use p11-kit i.e. the certificate store in /etc/ssl/certs. Doing this > caused extensions in Librewolf to stop working. Apparently, Mozilla has > a notion of "built-in" certificates (i.e. ones that contain the > nss-mozilla-ca-policy attribute) which is invalidated when using the > p11-kit module. Again, other distros ship a .p11-kit file which has the > attribute so there's no problem. Interesting, and I'm happy you are looking into this; I had a similar patch doing the symlink trick for nss, but I hadn't gotten as far as testing it. I think in light of this it'd be reasonable reverting to the certdata2pem.py Python script or something equivalent that would generate the .p11-kit files that seem to be valuable (I wasn't aware of these). A patch would be welcome (it would need to target a world-rebuild branch). An area we could improve would also be documenting how to use p11-kit in Guix, e.g. to add extra user certificates or disallow a single or all the default ones. -- Thanks, Maxim
