Re: Should we include nss-certs out of the box?
Hello! On Thu, Apr 25 2024, Maxim Cournoyer wrote: > Clément Lassieur writes: > >> On Wed, Apr 03 2024, Maxim Cournoyer wrote: >> >>> It's been Guix policy to let people choose whether to install or not TLS >>> root certificates and which one to their machine. While I applaud the >>> idea to have the users make a conscious decision about it, in practice I >>> suppose very few of us choose to *not* install any as that basically >>> breaks using web browsers, especially ones like IceCat which (by >>> default) ensures HTTPS is used on every page. >> >> I'd be surprised Icecat breaks from this as it uses its own cert >> database and allows HTTP when HTTPS doesn't work. > > I didn't know Icecat had its own cert database. > > About allowing HTTP, it can access pages using it, but not without going > through a "Continue despite security risks" dialog, and perhaps turning > off the HTTPS everywhere add-on for the page, which is installed by > default. Indeed! (Well it's not an add-on anymore, but a Firefox native mode called HTTPS-only.) https://support.mozilla.org/en-US/kb/https-only-prefs Cheers, Clément
Re: Should we include nss-certs out of the box?
Hello! Clément Lassieur writes: > On Wed, Apr 03 2024, Maxim Cournoyer wrote: > >> It's been Guix policy to let people choose whether to install or not TLS >> root certificates and which one to their machine. While I applaud the >> idea to have the users make a conscious decision about it, in practice I >> suppose very few of us choose to *not* install any as that basically >> breaks using web browsers, especially ones like IceCat which (by >> default) ensures HTTPS is used on every page. > > I'd be surprised Icecat breaks from this as it uses its own cert > database and allows HTTP when HTTPS doesn't work. I didn't know Icecat had its own cert database. About allowing HTTP, it can access pages using it, but not without going through a "Continue despite security risks" dialog, and perhaps turning off the HTTPS everywhere add-on for the page, which is installed by default. -- Thanks, Maxim
Re: Should we include nss-certs out of the box?
On Wed, Apr 03 2024, Maxim Cournoyer wrote: > It's been Guix policy to let people choose whether to install or not TLS > root certificates and which one to their machine. While I applaud the > idea to have the users make a conscious decision about it, in practice I > suppose very few of us choose to *not* install any as that basically > breaks using web browsers, especially ones like IceCat which (by > default) ensures HTTPS is used on every page. I'd be surprised Icecat breaks from this as it uses its own cert database and allows HTTP when HTTPS doesn't work. Kind regards, Clément
Re: Should we include nss-certs out of the box?
Fabio Natali writes: > For what it's worth, I put together a micro-patch and sent it over as a > follow-up to #70451. Pushed as 67a3a83170c038d2eb084d3f53a7ea7b033aea74. Thank you! Regards, Florian
Re: Should we include nss-certs out of the box?
On 2024-04-20, 11:06 +0100, Fabio Natali wrote: > I'll send an update here. Hi Maxim, There's a couple of mentions of 'nss-certs' in the manual that might be rephrased to reflect '65e8472a4b6fc6f66871ba0dad518b7d4c63595e'. For what it's worth, I put together a micro-patch and sent it over as a follow-up to #70451. https://issues.guix.gnu.org/70451#4 Thanks, cheers, Fabio. -- Fabio Natali https://fabionatali.com
Re: Should we include nss-certs out of the box?
On 2024-04-19, 11:25 -0400, Maxim Cournoyer wrote: > Could you please take a look at > '65e8472a4b6fc6f66871ba0dad518b7d4c63595e', which I hope didn't leave > no longer useful 'nss-certs' doc/examples behind ? Hi Maxim, absolutely, I should be able to give a look today or tomorrow. I'll send an update here. Thanks, best wishes, Fabio.
Re: Should we include nss-certs out of the box?
Hi Fabio, Fabio Natali writes: > Hi, > > Here's my attempt at adding 'nss-certs' to '%default-packages'. > > https://lists.gnu.org/archive/html/guix-patches/2024-04/msg01187.html > > I've removed the 'nss-certs' entry from the installer, as suggested by > Ludo, and I've updated the docs, hopefully all the relevant parts. Can > you think of anything else that may need to be updated? It seems we were working on a similar thing at a similar time :-). Could you please take a look at '65e8472a4b6fc6f66871ba0dad518b7d4c63595e', which I hope didn't leave no longer useful 'nss-certs' doc/examples behind ? -- Thanks, Maxim
Re: Should we include nss-certs out of the box?
Hello, Ludovic Courtès writes: [...] >> It apparently even makes it impossible to run 'guix pull', if I am to >> believe bug#62026. > > I don’t think that’s the case: see use of ‘le-certs’ in (guix scripts > pull). OK, good to know! > >> Should we do as in bug#62026 and have this package be part of the >> recommended basic installation? It'd be in the basic set of an >> operating-system packages (via its default %base-packages set). It >> could still be manipulated via the Guix API (filtered out/replaced with >> something else). >> >> Is anyone opposed to having nss-certs in %base-packages? > > No objection from me. I’m partly responsible for the initial choice to > not include nss-certs by default, but as you write, most likely everyone > installs it these days. > > Note that we’ll also need to remove that choice from the installer in > (gnu installer services). I went ahead and have now done so, and included a news entry for it. I've adjusted the OSes templates accordingly, the doc, and the installer in 65e8472a4b6fc6f66871ba0dad518b7d4c63595e. Let me know if I've missed anything. -- Thanks, Maxim
Re: Should we include nss-certs out of the box?
Hi, Here's my attempt at adding 'nss-certs' to '%default-packages'. https://lists.gnu.org/archive/html/guix-patches/2024-04/msg01187.html I've removed the 'nss-certs' entry from the installer, as suggested by Ludo, and I've updated the docs, hopefully all the relevant parts. Can you think of anything else that may need to be updated? Thanks, best wishes, Fabio. -- Fabio Natali https://fabionatali.com
Re: Should we include nss-certs out of the box?
Hi, Maxim Cournoyer skribis: > It's been Guix policy to let people choose whether to install or not TLS > root certificates and which one to their machine. While I applaud the > idea to have the users make a conscious decision about it, in practice I > suppose very few of us choose to *not* install any as that basically > breaks using web browsers, especially ones like IceCat which (by > default) ensures HTTPS is used on every page. Right. > It apparently even makes it impossible to run 'guix pull', if I am to > believe bug#62026. I don’t think that’s the case: see use of ‘le-certs’ in (guix scripts pull). > Should we do as in bug#62026 and have this package be part of the > recommended basic installation? It'd be in the basic set of an > operating-system packages (via its default %base-packages set). It > could still be manipulated via the Guix API (filtered out/replaced with > something else). > > Is anyone opposed to having nss-certs in %base-packages? No objection from me. I’m partly responsible for the initial choice to not include nss-certs by default, but as you write, most likely everyone installs it these days. Note that we’ll also need to remove that choice from the installer in (gnu installer services). Thanks! Ludo’.
Re: Should we include nss-certs out of the box?
I wonder if instead (or in addition to) a step should be added to the default profile to symlink nss-certs to /etc/ssl/certs/ca-certificates.crt? Consider running $ guix shell rust:cargo nss-certs -CN -- cargo search ox. On c9cd16c630 this will fail with --8<---cut here---start->8--- Updating crates.io index error: download of config.json failed Caused by: failed to download from `https://index.crates.io/config.json` Caused by: [60] SSL peer certificate or SSH remote key was not OK (server certificate verification failed. CAfile: none CRLfile: none) --8<---cut here---end--->8--- This is because /etc/ssl/certs doesn't exist in the shell's container. A user could work around this by running in the shell: --8<---cut here---start->8--- export SSL_CERT_FILE=$GUIX_ENVIRONMENT/etc/ssl/certs/ca-certificates.crt --8<---cut here---end--->8--- but this complicates the handle $ guix shell ... -- syntax. The only package that seems to escape this nonfunctional trap is git because the package definition explicitly sets a GIT_SSL_CAINFO search path specification. IMO, if we agree to add nss-certs to %base-packages, we should also set up a /etc/ssl/certs symlink to %default-profile-hooks. It's very odd to see `building CA certificate bundle...` printed to the console yet not be able to use https except for git in shell containers. Power users will still be able to override the normal behavior by setting the package-specific environment variables. This change would just change the default state from "nonfunctional" to "working". -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Should we include nss-certs out of the box?
On Wed, 03 Apr 2024 14:06:37 -0400 Maxim Cournoyer wrote: > Hi, > > It's been Guix policy to let people choose whether to install or not > TLS root certificates and which one to their machine. While I > applaud the idea to have the users make a conscious decision about > it, in practice I suppose very few of us choose to *not* install any > as that basically breaks using web browsers, especially ones like > IceCat which (by default) ensures HTTPS is used on every page. > > It apparently even makes it impossible to run 'guix pull', if I am to > believe bug#62026. > > Should we do as in bug#62026 and have this package be part of the > recommended basic installation? It'd be in the basic set of an > operating-system packages (via its default %base-packages set). It > could still be manipulated via the Guix API (filtered out/replaced > with something else). > > Is anyone opposed to having nss-certs in %base-packages? > Hello, IMO everything should work out of the box. Power users will be able to do their stuff if they need to, so the feature should be opt-out. -- Jan Wielkiewicz
Re: Should we include nss-certs out of the box?
Hi Maxim, On Wed, Apr 03 2024, Maxim Cournoyer wrote: > I applaud the idea to have the users make a conscious decision Who does? > It apparently even makes it impossible to run 'guix pull' More than that, the references to online sources in our package declarations are useless. Would it be possible to install nss-certs from source? > [nss-certs would] be in the basic set of an operating-system packages That strikes me as rational but it would be valuable to hear from the other side---if there is one. Kind regards Felix
Re: Should we include nss-certs out of the box?
On Wednesday, April 3rd, 2024 at 1:06 PM, Maxim Cournoyer wrote: > Is anyone opposed to having nss-certs in %base-packages? I applaud that plan. Not only that, I think that Guix should warn if you don't have nss-certs in your profile on a foreign distro (with a mechanism to suppress that, ofc) Lacking the nss-certs package causes all manner of trouble and is a stumbling block to adoption. It's practically a dependency; the ability to operate without it is kind of a party trick. Ryan
Should we include nss-certs out of the box?
Hi, It's been Guix policy to let people choose whether to install or not TLS root certificates and which one to their machine. While I applaud the idea to have the users make a conscious decision about it, in practice I suppose very few of us choose to *not* install any as that basically breaks using web browsers, especially ones like IceCat which (by default) ensures HTTPS is used on every page. It apparently even makes it impossible to run 'guix pull', if I am to believe bug#62026. Should we do as in bug#62026 and have this package be part of the recommended basic installation? It'd be in the basic set of an operating-system packages (via its default %base-packages set). It could still be manipulated via the Guix API (filtered out/replaced with something else). Is anyone opposed to having nss-certs in %base-packages? -- Thanks, Maxim
