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

  • Open
  • quality assurance status badge
Details
3 participants
  • Maxim Cournoyer
  • Tobias Geerinckx-Rice
  • raingloom
Owner
unassigned
Submitted by
raingloom
Severity
normal
R
R
raingloom wrote on 27 Jun 2020 05:35
(name . Guix Bugs)(address . bug-guix@gnu.org)
20200627053551.63452543@riseup.net
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.
T
T
Tobias Geerinckx-Rice wrote on 27 Jun 2020 11:53
(name . raingloom)(address . raingloom@riseup.net)(address . 42076@debbugs.gnu.org)
871rm0suma.fsf@nckx
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
R
R
raingloom wrote on 27 Jun 2020 22:16
(address . 42076@debbugs.gnu.org)
20200627221605.38116e75@riseup.net
On Sat, 27 Jun 2020 11:53:01 +0200
Tobias Geerinckx-Rice <me@tobias.gr> wrote:

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

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

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

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

Toggle quote (6 lines)
> 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.
Toggle quote (6 lines)
> I've not used GVFS & can't say anything sensible about it.
>
> Kind regards,
>
> T G-R

Thanks for the help!
M
M
Maxim Cournoyer wrote on 14 Jul 2022 05:36
(name . raingloom)(address . raingloom@riseup.net)(address . 42076@debbugs.gnu.org)
87sfn4xt5o.fsf@gmail.com
Hi raingloom,

raingloom <raingloom@riseup.net> writes:

Toggle quote (16 lines)
> 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
?
Your comment

Commenting via the web interface is currently disabled.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 42076
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