GNU bug report logs - #42076
SSL_CERT_* variables and GVFS (and probably more) are not initialized if you don't use GDM

Previous Next

Full log

Message #8 received at 42076 <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: raingloom <raingloom <at> riseup.net>
Cc: 42076 <at> debbugs.gnu.org
Subject: Re: bug#42076: SSL_CERT_* variables and GVFS (and probably more) are
 not initialized if you don't use GDM
Date: Sat, 27 Jun 2020 11:53:01 +0200

Hi!

Thanks for the bug report.  How are these two things related?  Did 
GVFS start working when you fixed your certs?  Is GVFS failing 
because of other unset search paths?  They should be tracked as 
separate bug #s otherwise.

It's not true that ‘SSL_CERT_* variables are not initialized if 
you don't use GDM’: they're initialised if a package declares a 
native-search-path requirement on them, and another package in the 
same profile provides matching files.

How were you failing to ‘download things’, ‘access the web’?  How 
did you fix it?

I see that wget doesn't declare any search-paths.  That's odd 
(bug?) but I don't use it.

I prefer curl, which does declare SSL_CERT_* search-paths: 
installing it will set SSL_CERT_{DIR,FILE} in the profile as long 
as there are (nss-)certs in that same profile to point at.

git, on the other hand, doesn't use SSL_CERT_*, but 
GIT_SSL_CAINFO.  Here too, users don't need to care about the 
variable(s) because Guix sets them up as soon as certs are 
installed alongside.

If you install the (nss-)certs to a different profile than all 
SSL_CERT_* consumers, this won't happen.  An ugly hack-around 
would be to add native-seach-paths entries to the providing 
packages which would unconditionally set them.  I'm not convinced 
this case is worth supporting.

I've not used GVFS & can't say anything sensible about it.

Kind regards,

T G-R

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.