bug#46779: GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates

bug#46779: GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates

[Maxim Cournoyer]

Hello,

Consider this:

$ guix environment --container --network -E SSL --expose=$SSL_CERT_FILE
--expose=$SSL_CERT_DIR --ad-hoc wget -- wget https://gnu.org

It works on a Guix System, but fails on a foreign distribution, even in
a profile where nss-certs were installed and with the above SSL
environment value properly set.

This is because GnuTLS, which wget uses, looks up the certificates under
the /etc/ssl/certs hard-coded location.  On Guix System, the
SSL_CERT_FILE is set to /etc/ssl/certs/ca-certificates.crt, which
explains why it works there.

We should patch GnuTLS so that it also honors the SSL_* environment
variables documented in the Guix manual.

Maxim

bug#46779: GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates

[Ludovic Courtès]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> We should patch GnuTLS so that it also honors the SSL_* environment
> variables documented in the Guix manual.

Note that (1) the SSL_* variables are originally from OpenSSL, and (2)
GnuTLS developers made the conscious decision to not honor any
environment variable, leaving it up to application developers to do
that.

That’s the reason we are in this situation.  See the thread at
<https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00237.html>.

Now, I agree it’s inconvenient for those applications that don’t do
anything.  Perhaps we should check if it’s reasonable to report it
upstream when we encounter such issues, or if there’s just too many of
them?

Thanks,
Ludo’.

bug#46779: GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates

[Mark H Weaver]

Ludovic Courtès <ludo@gnu.org> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> We should patch GnuTLS so that it also honors the SSL_* environment
>> variables documented in the Guix manual.
>
> Note that (1) the SSL_* variables are originally from OpenSSL, and (2)
> GnuTLS developers made the conscious decision to not honor any
> environment variable, leaving it up to application developers to do
> that.
>
> That’s the reason we are in this situation.  See the thread at
> <https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00237.html>.

That thread is worth reading, but for those who are short on time, I
want to call attention to a specific point I made:

  However, GnuTLS does not support an environment variable setting, so we
  would have to patch the code (add_system_trust in lib/system.c).  I
  strongly considered doing this, but I'm worried about the possible
  security implications.  For example, consider a setuid program that uses
  GnuTLS and assumes that the person who ran the program will not be
  capable of changing the trust store that GnuTLS uses.  This assumption
  would be correct for the upstream GnuTLS, but not for ours.

<https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00245.html>

     Thanks,
       Mark

bug#46779: GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates

[Roel Janssen]

On Fri, 2021-03-19 at 19:13 -0400, Mark H Weaver wrote:
> Ludovic Courtès <ludo@gnu.org> writes:
> 
> > Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
> > 
> > > We should patch GnuTLS so that it also honors the SSL_*
> > > environment
> > > variables documented in the Guix manual.
> > 
> > Note that (1) the SSL_* variables are originally from OpenSSL, and
> > (2)
> > GnuTLS developers made the conscious decision to not honor any
> > environment variable, leaving it up to application developers to do
> > that.
> > 
> > That’s the reason we are in this situation.  See the thread at
> > <
> > https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00237.html
> > >.
> 
> That thread is worth reading, but for those who are short on time, I
> want to call attention to a specific point I made:
> 
>   However, GnuTLS does not support an environment variable setting,
> so we
>   would have to patch the code (add_system_trust in lib/system.c).  I
>   strongly considered doing this, but I'm worried about the possible
>   security implications.  For example, consider a setuid program that
> uses
>   GnuTLS and assumes that the person who ran the program will not be
>   capable of changing the trust store that GnuTLS uses.  This
> assumption
>   would be correct for the upstream GnuTLS, but not for ours.
> 
> <https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00245.html>
> 

Would it be an idea to propose the patches, or the idea, for supporting
the SSL_* variables to the GnuTLS developers? Or is there a more
fundamental reason why GnuTLS does not support changing certificate
stores at run-time?

Perhaps I have missed a solution that has already made it in Guix. If
that is the case, I would like to know about it. :)

Kind regards,
Roel Janssen

bug#46779: GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates

[Mark H Weaver]

Roel Janssen <roel@gnu.org> writes:

> On Fri, 2021-03-19 at 19:13 -0400, Mark H Weaver wrote:
>> Ludovic Courtès <ludo@gnu.org> writes:
>> 
>> > Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>> > 
>> > > We should patch GnuTLS so that it also honors the SSL_*
>> > > environment
>> > > variables documented in the Guix manual.
>> > 
>> > Note that (1) the SSL_* variables are originally from OpenSSL, and
>> > (2)
>> > GnuTLS developers made the conscious decision to not honor any
>> > environment variable, leaving it up to application developers to do
>> > that.
>> > 
>> > That’s the reason we are in this situation.  See the thread at
>> > <
>> > https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00237.html
>> > >.
>> 
>> That thread is worth reading, but for those who are short on time, I
>> want to call attention to a specific point I made:
>> 
>>   However, GnuTLS does not support an environment variable setting,
>> so we
>>   would have to patch the code (add_system_trust in lib/system.c).  I
>>   strongly considered doing this, but I'm worried about the possible
>>   security implications.  For example, consider a setuid program that
>> uses
>>   GnuTLS and assumes that the person who ran the program will not be
>>   capable of changing the trust store that GnuTLS uses.  This
>> assumption
>>   would be correct for the upstream GnuTLS, but not for ours.
>> 
>> <https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00245.html>
>> 
>
> Would it be an idea to propose the patches, or the idea, for supporting
> the SSL_* variables to the GnuTLS developers?

Sure, please feel free to discuss it with them.

> Or is there a more fundamental reason why GnuTLS does not support
> changing certificate stores at run-time?

I don't know.  It's been many years since I looked at this.

     Thanks,
       Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.

bug#46779: GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates

[Roel Janssen]

On Fri, 2021-10-08 at 15:00 -0400, Mark H Weaver wrote:
> Roel Janssen <roel@gnu.org> writes:
> 
> > On Fri, 2021-03-19 at 19:13 -0400, Mark H Weaver wrote:
> > > Ludovic Courtès <ludo@gnu.org> writes:
> > > 
> > > > Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
> > > > 
> > > > > We should patch GnuTLS so that it also honors the SSL_*
> > > > > environment
> > > > > variables documented in the Guix manual.
> > > > 
> > > > Note that (1) the SSL_* variables are originally from OpenSSL, and
> > > > (2)
> > > > GnuTLS developers made the conscious decision to not honor any
> > > > environment variable, leaving it up to application developers to do
> > > > that.
> > > > 
> > > > That’s the reason we are in this situation.  See the thread at
> > > > <
> > > > https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00237.html
> > > > > .
> > > 
> > > That thread is worth reading, but for those who are short on time, I
> > > want to call attention to a specific point I made:
> > > 
> > >   However, GnuTLS does not support an environment variable setting,
> > > so we
> > >   would have to patch the code (add_system_trust in lib/system.c).  I
> > >   strongly considered doing this, but I'm worried about the possible
> > >   security implications.  For example, consider a setuid program that
> > > uses
> > >   GnuTLS and assumes that the person who ran the program will not be
> > >   capable of changing the trust store that GnuTLS uses.  This
> > > assumption
> > >   would be correct for the upstream GnuTLS, but not for ours.
> > > 
> > > <https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00245.html>
> > > 
> > 
> > Would it be an idea to propose the patches, or the idea, for supporting
> > the SSL_* variables to the GnuTLS developers?
> 
> Sure, please feel free to discuss it with them.

I submitted a feature request here:
https://gitlab.com/gnutls/gnutls/-/issues/1279

> > Or is there a more fundamental reason why GnuTLS does not support
> > changing certificate stores at run-time?
> 
> I don't know.  It's been many years since I looked at this.
> 

Well, thank you for having looked at it in the past. :)
Hopefully we will find out more by means of the feature request I submitted.

Kind regards,
Roel Janssen

bug#46779: GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates

[Maxim Cournoyer]

Hi,

I was looking at what Nix does, and they carry this patch, under
pkgs/development/libraries/gnutls/nix-ssl-cert-file.patch:

--8<---------------cut here---------------start------------->8---
allow overriding system trust store location via $NIX_SSL_CERT_FILE

--- a/lib/system/certs.c
+++ b/lib/system/certs.c
@@ -404,6 +404,10 @@ gnutls_x509_trust_list_add_system_trust(gnutls_x509_trust_list_t list,
 					unsigned int tl_flags,
 					unsigned int tl_vflags)
 {
-	return add_system_trust(list, tl_flags | GNUTLS_TL_NO_DUPLICATES,
-				tl_vflags);
+	tl_flags = tl_flags|GNUTLS_TL_NO_DUPLICATES;
+	const char *file = secure_getenv("NIX_SSL_CERT_FILE");
+	return file
+		? gnutls_x509_trust_list_add_trust_file(
+			list, file, NULL/*CRL*/, GNUTLS_X509_FMT_PEM, tl_flags, tl_vflags)
+		: add_system_trust(list, tl_flags, tl_vflags);
 }
--8<---------------cut here---------------end--------------->8---

I guess we could rename NIX_SSL_CERT_FILE to just SSL_CERT_FILE in the
above patch and add the $SSL_CERT_FILE search path to bring us closer to
what OpenSSL supports?

I got interested in this problem again as the glib-networking now expect
a valid trust store to exist, and fails half its test suite without it
(and gnutls expecting a fixed location, I can't (easily?) fix this in
the build environment).

-- 
Thanks,
Maxim

bug#46779: GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates

[Ludovic Courtès]

Hello,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> I guess we could rename NIX_SSL_CERT_FILE to just SSL_CERT_FILE in the
> above patch and add the $SSL_CERT_FILE search path to bring us closer to
> what OpenSSL supports?

As a rule of thumb, I would avoid diverging from upstream, especially
for touchy points like this one: it quickly gets problematic when a
same-named package behaves differently across distros.

In this case, because GnuTLS does not honor any environment variables,
applications/libraries linked against it have to provide their own
mechanism for users to specify the certificate search path.  Normally,
they already do that.

WDYT?

Ludo’.