[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#42076: SSL_CERT_* variables and GVFS (and probably more) are not ini
From: |
raingloom |
Subject: |
bug#42076: SSL_CERT_* variables and GVFS (and probably more) are not initialized if you don't use GDM |
Date: |
Sat, 27 Jun 2020 22:16:05 +0200 |
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!