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
?