[arch-dev-public] Rethinking our CA certificate setup
Hi guys, I'm currently at FrOSCon with Pierre and an expert from CAcert.org and we're thinking of changes to our certificate setup. The current issues are: - Mozilla NSS uses its own root store and not /etc/ssl/certs - ca-certificates ships outdated Mozilla roots - Shipping additional roots outside ca-certificates is difficult, requiring patching /etc/ca-certificates.conf To solve these issues, we thought of making the following changes: - Attach NSS to p11-kit so it uses our root store (easily done by replacing /usr/lib/libnssckbi.so with a symlink to p11-kit-proxy.so) - Patch the update-ca-certificates script to read /etc/ca-certificates/conf.d instead of /etc/ca-certificates.conf - Split the current Mozilla roots from the NSS package in the ca-certificates format, shipping /etc/ca-certificates/conf.d/mozilla.conf - Create a package shipping the CAcert.org roots in a similar way - Ship the update-ca-certificates script in a ca-certificates-utils package, which the certificate packages depend on - ca-certificates becomes a metapackage depending on the -mozilla and -cacert packages Comments are welcome. Unless we get objections, we're going to start making these changes. Hopefully we can be done today and push the result to [testing]. Greetings, Jan
[2014-08-24 11:47:56 +0200] Jan Alexander Steffens:
So we'd have three ca-certificates-* packages? If this is this only to allow users to remove the bundles (mozilla or cacert) they do not trust, then couldn't we instead just keep everything in one package; simply putting the files /etc/ca-certificates/conf.d/{mozilla,cacert}.conf in the backup array would allow anyone to override them, so disabling a bundle would also be super easy... Other than the fragmentation of packages (my new pet gripe), your plan sounds great! Cheers. -- Gaetan
On Sun, Aug 24, 2014 at 12:06 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
I don't want to stick either update-ca-certificates or the CAcert.org certificates into the NSS PKGBUILD, so we will have at least two PKGBUILDs and three packages involved here: ca-certificates/PKGBUILD: - sources: Debian ca-certificates, CACert.org certificates - pkgnames: ca-certificates nss/PKGBUILD: - sources: Mozilla NSS - packages: nss ca-certificates-mozilla Since Debian and CACert.org aren't really related, I wanted to do another split. -cacert and -mozilla both provide packages; the rest is infrastructure. One could conceive of other provider packages. So our proposed setup is: ca-certificates/PKGBUILD: - sources: Debian ca-certificates - pkgnames: ca-certificates ca-certificates-utils ca-certificates-cacert/PKGBUILD: - sources: CACert.org certificates - pkgnames: ca-certificates-cacert nss/PKGBUILD: - sources: Mozilla NSS - pkgnames: nss ca-certificates-mozilla The package ca-certificates is empty and just depends on -mozilla and -cacert to ensure a sane default setup. The package ca-certificates-utils provides ca-certificates, so a minimum install with no certificate provider packages is possible.
On Sun, Aug 24, 2014 at 11:47 AM, Jan Alexander Steffens < jan.steffens@gmail.com> wrote:
Agreed, the current situation is far from optimal. On a related note currently replacing the libnssckbi.so lib with any other drop-in replacement could be handled better. I have been symlinking /usr/lib/pkcs11/p11-kit-trust.so to /usr/lib/libnssckbi.so to use the trust policy module [1] for quite some time and the only way to not let pacman screw this setup is to add "usr/lib/libnssckbi.so" to both NoUpgrade and NoExtract in pacman.conf. [1] http://p11-glue.freedesktop.org/doc/p11-kit/trust-module.html
On Sunday, August 24, 2014 11:47:56 Jan Alexander Steffens wrote:
A quick search shows that we have more packages shipping their own (maybe outdated) CA certificates copy in package. Since we are already on the topic about the inconsistency between nss and ca-certificates, I would like to also bring these up. I'd think it a good idea to make them use /etc/ssl/certs too. (Maybe not the ones in examples? Thoughts?) perl-mozilla-ca ships usr/share/perl5/vendor_perl/Mozilla/CA/cacert.pem - serves as the reference for some other projects, for example spamassassin, gnucash, bugzilla, shutter... - There was a discussion around this package in Debian [1], which resulted in not adding this package at all. python{,2}-pip ship usr/lib/python{3.4,2.7}/site- packages/pip/_vendor/requests/cacert.pem - We already have a patch for python{,2}-requests to use ca-certificates [2], but the embedded version in pip didn't use it. python{,2}-certifi ship usr/lib/python{3.4,2.7}/site- packages/certifi/cacert.pem - only affects tornado for now, consider removing the package and patching tornado? vagrant ships opt/vagrant/embedded/cacert.pem - looks like it has an option to use system-wide ca-certificates [3], would we patch it or simply remove the embedded version? goagent ships usr/share/goagent/local/cacert.pem - looks like a simple patching. And some others I didn't look further into: - opensips ships etc/opensips/tls/rootCA/cacert.pem - owncloud ships usr/share/webapps/owncloud/apps/files_external/3rdparty/aws- sdk-php/Guzzle/Http/Resources/cacert.pem, usr/share/webapps/owncloud/apps/files_external/3rdparty/google-api-php- client/src/io/cacerts.pem, ... - swi-prolog ships usr/lib/swipl-6.6.5/doc/packages/examples/ssl/etc/demoCA/cacert.pem - erlang/erlang-nox ship usr/lib/erlang/lib/ssl-5.3.5/examples/certs/etc/client/cacerts.pem, usr/lib/erlang/lib/ssl-5.3.5/examples/certs/etc/server/cacerts.pem [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698101 [2] https://projects.archlinux.org/svntogit/community.git/tree/trunk/certs.patch... [3] https://www.digitalocean.com/community/tutorials/how-to-use-digitalocean-as-... Regards, Felix Yan
On Sun, Aug 24, 2014 at 11:47 AM, Jan Alexander Steffens <jan.steffens@gmail.com> wrote:
Firefox isn't quite happy yet with the change, see https://bugs.archlinux.org/task/41689: Addons fail to install or update. It seems this is due to Firefox depending on NSS internals - specifically, addons must be signed by certificates validated by the built-in trusted root store, which is matched by name. Fedora was affected as well: https://bugzilla.redhat.com/show_bug.cgi?id=966424 Upstream report, arguing for the check to be removed: https://bugzilla.mozilla.org/show_bug.cgi?id=880269 Now we can: a. Patch p11-kit to rename the store; the easy way. b. Patch Firefox and Thunderbird and SeaMonkey to not require the name to match; the hard way, and the one Fedora chose. c. Revert the change that links NSS to p11-kit; rather not, as it makes it really hard to control the root store. Opinions?
On 26 August 2014 21:15, Jan Alexander Steffens <jan.steffens@gmail.com> wrote:
Hi Pierre, hi Jan, So the "ca-certificates-utils" from testing (20140923-5) declares a "provides" and "conflict" on "ca-certificates-java". Unfortunately jre and jdk packages use a "init-jks-keystore" script provided by "ca-certificates-java" but not "ca-certificates-utils". This scripts only computes file /etc/ssl/certs/java/cacerts which is actually also computed by "update-ca-trust". So I could just make jre and jdk packages depend on ca-certificates-utils and then "ca-certificates-java" could be dropped: is that the whole plan?
On Sun, Nov 16, 2014 at 3:54 PM, Guillaume Alaux <guillaume@alaux.net> wrote:
Yes. Since p11-kit can construct the Java cert store and update-ca-trust always does so, ca-certificates-java becomes obsolete.
On 16 November 2014 16:13, Jan Alexander Steffens <jan.steffens@gmail.com> wrote:
Excellent. I am going to rebuild OpenJDK7 and 8 and will push them to testing then.
participants (6)
-
Felix Yan
-
Gaetan Bisson
-
Guillaume Alaux
-
Guillaume ALAUX
-
Jan Alexander Steffens
-
Massimiliano Torromeo