[arch-general] 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:
- 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
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:
[2014-08-24 11:47:56 +0200] Jan Alexander Steffens:
- 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
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!
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:
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
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?
participants (2)
-
Gaetan Bisson
-
Jan Alexander Steffens