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

[raingloom <raingloom@riseup.net>]

On Sat, 27 Jun 2020 11:53:01 +0200
Tobias Geerinckx-Rice <me@tobias.gr> wrote:

> 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.

No idea, I don't know enough about GVFS to know how it's initalized.
But this falls into the same category for me, ie.: a bunch of things
are not initalized.
But actually I've already made a bug report about it, it's just that
nobody replied to it. See 41927.

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

SSL errors. They can probably be worked around, but it's annoying. And
turning SSL off isn't the solution.
I fixed it by setting SSL_CERT_{DIR,FILE} to the entries in /etc.
Having nss-certs in the ad-hoc environment was not enough. for
instance, Netsurf still does not work. (guix environment --ad-hoc
nss-certs netsurf -- netsurf-gtk3)

> 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.

Putting curl in the ad-hoc environment does fix it for Netsurf. So
that's a bug in the Netsurf package I guess.

> 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.

Git did work with `guix environment --ad-hoc nss-certs`, but since
nss-certs is installed globally, I don't understand why that should be
necessary.
Or, well, I kind of do understand now, but I consider this a bug.
The templates in gnu/system/examples/ all imply that nss-certs
is necessary for HTTPS and that installing it system wide is enough.
And it should be enough.

> 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 don't think having undocumented broken edge cases is a good idea.
 
> I've not used GVFS & can't say anything sensible about it.
> 
> Kind regards,
> 
> T G-R

Thanks for the help!