GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates

  • Open
  • quality assurance status badge
Details
4 participants
  • Ludovic Courtès
  • Maxim Cournoyer
  • Mark H Weaver
  • Roel Janssen
Owner
unassigned
Submitted by
Maxim Cournoyer
Severity
normal
M
M
Maxim Cournoyer wrote on 25 Feb 2021 21:03
(name . bug-guix)(address . bug-guix@gnu.org)
87im6f9aq2.fsf@gmail.com
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
L
L
Ludovic Courtès wrote on 1 Mar 2021 10:54
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 46779@debbugs.gnu.org)
87y2f7td00.fsf@gnu.org
Hi,

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

Toggle quote (3 lines)
> 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

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’.
M
M
Mark H Weaver wrote on 20 Mar 2021 00:13
(address . 46779@debbugs.gnu.org)
87o8fen3d0.fsf@netris.org
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (13 lines)
> 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.


Thanks,
Mark
R
R
Roel Janssen wrote on 7 Oct 2021 12:28
(address . 46779@debbugs.gnu.org)
b17ae2a486ca08c9de8d88127c3bc9df68b03f2b.camel@gnu.org
On Fri, 2021-03-19 at 19:13 -0400, Mark H Weaver wrote:
Toggle quote (36 lines)
> 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
M
M
Mark H Weaver wrote on 8 Oct 2021 21:00
(address . 46779@debbugs.gnu.org)
87k0in1gur.fsf@netris.org
Roel Janssen <roel@gnu.org> writes:

Toggle quote (40 lines)
> 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.

Toggle quote (3 lines)
> 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.
R
R
Roel Janssen wrote on 11 Oct 2021 12:59
(address . 46779@debbugs.gnu.org)
02120ab2080916fba3d6ff6b6909e4d478739b10.camel@gnu.org
On Fri, 2021-10-08 at 15:00 -0400, Mark H Weaver wrote:
Toggle quote (44 lines)
> 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:

Toggle quote (6 lines)
> > 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
M
M
Maxim Cournoyer wrote 6 days ago
(name . Roel Janssen)(address . roel@gnu.org)
87pln3azkd.fsf@gmail.com
Hi,

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

Toggle snippet (19 lines)
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);
}

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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 46779@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 46779
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch