Re: [arch-dev-public] Rethinking our CA certificate setup
On 26 August 2014 21:15, Jan Alexander Steffens jan.steff...@gmail.com wrote: On Sun, Aug 24, 2014 at 11:47 AM, Jan Alexander Steffens jan.steff...@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? 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?
Re: [arch-dev-public] Rethinking our CA certificate setup
On Sun, Nov 16, 2014 at 3:54 PM, Guillaume Alaux guilla...@alaux.net wrote: 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? Yes. Since p11-kit can construct the Java cert store and update-ca-trust always does so, ca-certificates-java becomes obsolete.
Re: [arch-dev-public] Rethinking our CA certificate setup
On 16 November 2014 16:13, Jan Alexander Steffens jan.steff...@gmail.com wrote: On Sun, Nov 16, 2014 at 3:54 PM, Guillaume Alaux guilla...@alaux.net wrote: 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? Yes. Since p11-kit can construct the Java cert store and update-ca-trust always does so, ca-certificates-java becomes obsolete. Excellent. I am going to rebuild OpenJDK7 and 8 and will push them to testing then.
Re: [arch-dev-public] Rethinking our CA certificate setup
On Sun, Aug 24, 2014 at 11:47 AM, Jan Alexander Steffens jan.steff...@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?
[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
Re: [arch-dev-public] Rethinking our CA certificate setup
[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
Re: [arch-dev-public] Rethinking our CA certificate setup
On Sun, Aug 24, 2014 at 11:47 AM, Jan Alexander Steffens jan.steff...@gmail.com wrote: 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 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
Re: [arch-dev-public] Rethinking our CA certificate setup
On Sun, Aug 24, 2014 at 12:06 PM, Gaetan Bisson bis...@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.
Re: [arch-dev-public] Rethinking our CA certificate setup
On Sunday, August 24, 2014 11:47:56 Jan Alexander Steffens wrote:
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
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?h=packages/python-requests
[3]
https://www.digitalocean.com/community/tutorials/how-to-use-digitalocean-as-your-provider-in-vagrant-on-an-ubuntu-12-10-vps
Regards,
Felix Yan
signature.asc
Description: This is a digitally signed message part.
