Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Mark H Weaver <mhw@netris.org>]

Andreas Enge <andreas@enge.fr> writes:

> On Mon, Feb 02, 2015 at 06:11:02PM -0500, Mark H Weaver wrote:
>> +             "--with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt")))
>
> I would suggest to use --with-default-trust-store-dir=/etc/ssl/certs instead.
> The option is available in gnutls-3.3.12, which I am building in the
> wip-gnutls branch right now, and which looks good to push.
>
> This would allow us to provide not only a single file, but to potentially
> merge different trust stores. We could also, for instance, prepare a package
> per certification authority, so that the user could install exactly the
> ones he trusts.

It turns out there's a problem with our lack of a single-file
certificate bundle.  Curl has two options to specifying the location of
the trust store: CURLOPT_CAINFO names a single file, and CURLOPT_CAPATH
names a directory.  Unfortunately, although CURLOPT_CAINFO is supported
on both GnuTLS and OpenSSL, CURLOPT_CAPATH is only supported on OpenSSL.

Git uses Curl to fetch from https URLs.  Git supports both
GIT_SSL_CAINFO and GIT_SSL_CAPATH environment variables, and pass those
on to CURLOPT_CAINFO and CURLOPT_CAPATH.

I've set GIT_SSL_CAINFO in my environment for a long time to make Git
check certificates properly on GuixSD, but without the single-file
certificate bundle, I've lost certificate checking in Git.

I see a few ways forward:

(1) Curl's GnuTLS backend could grow support for CURLOPT_CAPATH.

(2) We could create single-file certificate bundles in our certificate
    packages and add support to our profile builder to merge them
    together properly.

(3) We could build Curl with OpenSSL for now.

Option (1) seems best, if someone wants to volunteer for that job very
soon.  In the meantime, I like option (2).

What do you think?

      Mark