From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: [PATCHES] profiles: Produce a single-file CA certificate bundle Date: Tue, 03 Mar 2015 14:33:07 -0500 Message-ID: <8761ahlvv0.fsf@netris.org> References: <87r3u7di49.fsf@netris.org> <20150204123652.GA21908@debian.eduroam.u-bordeaux.fr> <87wq3jah2w.fsf@netris.org> <20150215091632.GA9692@debian> <87sie79km0.fsf@netris.org> <87mw441fdp.fsf@gnu.org> <87sidvhx0t.fsf@netris.org> <87zj7v2gmf.fsf_-_@gnu.org> <87fv9medxv.fsf_-_@netris.org> <87bnkaeb8y.fsf@netris.org> <87a8zuntw7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSsYr-0001uh-5I for guix-devel@gnu.org; Tue, 03 Mar 2015 14:32:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSsYn-00036J-TC for guix-devel@gnu.org; Tue, 03 Mar 2015 14:32:57 -0500 In-Reply-To: <87a8zuntw7.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Tue, 03 Mar 2015 13:32:40 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Mark H Weaver skribis: > >> I think perhaps that we should be more selective in the certs we add to >> ca-certificates.crt. Debian has a configuration file >> /etc/ca-certificates.conf, and only adds certificates that are >> explicitly listed there to ca-certificates.crt. > > Based on what you write, I agree we should be more selective, but I=E2=80= =99m > not sure how we can do that. > > So far the approach has been to trust Mozilla=E2=80=99s bundle, which is > apparently not such a great idea. But what can we trust here? The problem was not Mozilla's certificate bundle, it's how we were using it. We initially assumed that it would only contain trusted certificates, but this is not the case. They annotate the certificates with trust metadata that we need to pay attention to. Debian's ca-certificates package uses a variant of 'certdata2pem.py' that only outputs trusted certificates. The variant of that script that we're using from Fedora outputs untrusted certificates as well, but Fedora then takes care to install only the trusted ones. The trust information is more than just a simple boolean. There are many distinct "trust types" that can be assigned, e.g. server-auth, code-signing, email-protection, etc. Fedora's system for handling CA certificates seems to be vastly more sophisticated than Debian's. All of the single-file bundles are considered "legacy", and Fedora is able to produce multiple bundles containing certs trusted for different purposes. Doing this job properly will require more research, but it seems to me that we should be looking to Fedora for guidance: http://pkgs.fedoraproject.org/cgit/ca-certificates.git http://pkgs.fedoraproject.org/cgit/openssl.git http://pkgs.fedoraproject.org/cgit/gnutls.git Andreas Enge writes: > If we decide to remove certificates, this should not only be done in the > aggregation phase into one file. They should be removed at the end of the > nss-certs build, so that also the single certificate files will disappear. > What is left over can be collected into one file as is done now. Agreed. For now, I've pushed my recently proposed commits (to support certificate stores in profiles) along with changes to our 'nss-certs' package to only install certificates that are annotated with a non-empty "openssl-trust=3D" comment by our 'certdata2pem.py' (from Fedora). > On Tue, Mar 03, 2015 at 01:43:38PM +0100, Ludovic Court=C3=A8s wrote: >> I just checked the source and OpenSSL itself does not use SSL_CERT_FILE >> nor SSL_CERT_DIR at all. Lynx does use SSL_CERT_FILE, but that=E2=80=99= s really >> in Lynx, not in libssl. So I don=E2=80=99t think there should be a sear= ch path >> specification for OpenSSL. This is unfortunate, but it looks like we >> can=E2=80=99t do much. >=20 > I just did a "strings" and "grep" on the binaries and libs. SSL_CERT_DIR > appears in bin/c_rehash and lib/libcrypto.so, and SSL_CERT_FILE also appe= ars > in the latter. >=20 > In the source code, > $ find -type f -exec grep -H SSL_CERT_DIR {} \; > yields: >=20 > ./crypto/cryptlib.h:# define X509_CERT_DIR_EVP "SSL_CERT_DIR" [...] > ./crypto/cryptlib.h:# define X509_CERT_FILE_EVP "SSL_CERT_FILE" Right. I've forgotten the details, but about a year ago I looked through the maze of OpenSSL code and determined that at least in some cases, OpenSSL would honor those variables. I guess the application can specify whether or not to load the system trust store. Mark