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

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

[raingloom]

Hi all!

As the subject says, the initialization of the all important
environment variables that Guix is built around are rather lacking.
I had a lot of SSL related errors for weeks until I figured out that it
was caused by SSL_CERT_{DIR,FILE} not being set. I consider this rather
serious as it makes it difficult to use git, download things, or even
access the web to find help in debugging the issue.

The other thing that is not set up is GVFS. This used to be an issue on
the default GDM based setups as well, but has been fixed a few months
ago. However, it was evidently not fixed universally, as seemingly
every other way of logging in does not start GVFS.

If users are expected to set this up for themselves, then we need
proper documentation on where it should be done, but ideally these
services should be working even in a plain console login.

I hope we can actually fix this properly this time.

My particular setup is SDDM+Sway+Zsh, but I've tested others as well
and they all failed.
My other machine uses GDM+i3 and that has no issues.

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

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

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

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

[raingloom]

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!

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

[Maxim Cournoyer]

Hi raingloom,

raingloom <raingloom@riseup.net> writes:

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

I agree the user experience often suffers from the fact that:

1. it's not obvious that consumers applications are the ones typically
causing environment variables to be defined. 

2. the system and user profiles are not merged, which often lead to
surprises (I have this in my operating-system, and that in my user
profile, and they don't work together!).

1. would be (mostly?) addressed with #22138, and 2. with #20255.  If
you'd like to participate in fixing these, there are at least a patch to
try in 20255, I believe.

Given these issues are known and tracked already, I'll close this bug.

Thanks,

Maxim