unofficial mirror of bug-guix@gnu.org 
 help / color / Atom feed
* bug#42076: SSL_CERT_* variables and GVFS (and probably more) are not initialized if you don't use GDM
@ 2020-06-27  3:35 raingloom
  2020-06-27  9:53 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
  0 siblings, 1 reply; 3+ messages in thread
From: raingloom @ 2020-06-27  3:35 UTC (permalink / raw)
  To: 42076

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.




^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#42076: SSL_CERT_* variables and GVFS (and probably more) are not initialized if you don't use GDM
  2020-06-27  3:35 bug#42076: SSL_CERT_* variables and GVFS (and probably more) are not initialized if you don't use GDM raingloom
@ 2020-06-27  9:53 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
  2020-06-27 20:16   ` raingloom
  0 siblings, 1 reply; 3+ messages in thread
From: Tobias Geerinckx-Rice via Bug reports for GNU Guix @ 2020-06-27  9:53 UTC (permalink / raw)
  To: raingloom; +Cc: 42076

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




^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#42076: SSL_CERT_* variables and GVFS (and probably more) are not initialized if you don't use GDM
  2020-06-27  9:53 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
@ 2020-06-27 20:16   ` raingloom
  0 siblings, 0 replies; 3+ messages in thread
From: raingloom @ 2020-06-27 20:16 UTC (permalink / raw)
  To: 42076

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!




^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-27  3:35 bug#42076: SSL_CERT_* variables and GVFS (and probably more) are not initialized if you don't use GDM raingloom
2020-06-27  9:53 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2020-06-27 20:16   ` raingloom

unofficial mirror of bug-guix@gnu.org 

Archives are clonable:
	git clone --mirror https://yhetil.org/guix-bugs/0 guix-bugs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-bugs guix-bugs/ https://yhetil.org/guix-bugs \
		bug-guix@gnu.org
	public-inbox-index guix-bugs

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.bugs
	nntp://news.gmane.io/gmane.comp.gnu.guix.bugs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git