Should we include nss-certs out of the box?

Should we include nss-certs out of the box?

[Maxim Cournoyer]

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

Re: Should we include nss-certs out of the box?

[Ryan Prior]

On Wednesday, April 3rd, 2024 at 1:06 PM, Maxim Cournoyer <maxim.cournoyer@gmail.com> 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

Re: Should we include nss-certs out of the box?

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

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?

[Jan Wielkiewicz]

On Wed, 03 Apr 2024 14:06:37 -0400
Maxim Cournoyer <maxim.cournoyer@gmail.com> 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?

[Richard Sent]

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

[Ludovic Courtès]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> 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?

[Fabio Natali]

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?

[Maxim Cournoyer]

Hello,

Ludovic Courtès <ludo@gnu.org> 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?

[Maxim Cournoyer]

Hi Fabio,

Fabio Natali <me@fabionatali.com> 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?

[Fabio Natali]

On 2024-04-19, 11:25 -0400, Maxim Cournoyer <maxim.cournoyer@gmail.com> 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?

[Fabio Natali]

On 2024-04-20, 11:06 +0100, Fabio Natali <me@fabionatali.com> 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?

[pelzflorian (Florian Pelz)]

Fabio Natali <me@fabionatali.com> 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?

[Clément Lassieur]

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?

[Maxim Cournoyer]

Hello!

Clément Lassieur <clement@lassieur.org> 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?

[Clément Lassieur]

Hello!

On Thu, Apr 25 2024, Maxim Cournoyer wrote:

> Clément Lassieur <clement@lassieur.org> 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