Re: /etc/ssl/certs and the certificate bundle

[Mark H Weaver]

address@hidden (Ludovic Courtès) writes:

> Mark H Weaver <address@hidden> skribis:
>
>> The single-file bundle is just a concatenation of all the individual PEM
>> data, starting with "-----BEGIN CERTIFICATE-----" and ending with
>> "-----END CERTIFICATE-----", including those delimiters.
>>
>> The only caveat is that the individual PEM files are not required to
>> have a newline after the "-----END CERTIFICATE-----", but in the
>> single-file cert bundle, we must ensure that the newline is present.
>> See <https://bugs.debian.org/635570>.
>
> OK, I’ve implemented this for GuixSD in commit 993300f.  Thanks to you
> and Andreas for your help.

Thank you!

>> In order to support multiple packages containing CA certs, it would be
>> good to handle creation of the single-file cert bundle in the profile
>> generation code, analogous to our handling of info "dir" files.  This
>> would allow us to create additional cert packages (e.g. one for
>> CAcert.org).
>>
>> I think it belongs in the profile generation code for the benefit of
>> users running Guix packages on top of another distro, where they might
>> not have root access.  They can simply set GIT_SSL_CAINFO and
>> SSL_CERT_FILE to ~/.guix-profile/etc/ssl/ca-certificates.crt
>>
>> What do you think?
>
> It’s a good but as of yet unimplemented idea.
>
> Although I now realize we could perhaps simple move the
> ‘certificate-bundle’ procedure to (guix profile), add the certificate
> package to the system profile, and make /etc/ssl a symlink to
> /run/current-system/profile/etc/ssl.

I think this would be ideal.

> However there’s the complication that all the files of ‘nss-certs’ would
> still be there in addition to the bundle.  Hmm.

That's a feature, not a bug.  It is more efficient to look up the
individual files by their hash-named symlinks than to read the entire
certificate bundle as one file.  The only problem is that some
combinations of software don't yet support this mode.

For example, libcurl (used by git) only supports the single-file when it
is linked with GnuTLS.  When linked with OpenSSL it supports both modes.
(This is a limitation of libcurl's backend for GnuTLS, not an inherent
problem with GnuTLS.)

    Thanks,
      Mark