GNU bug report logs - #70926
Having default nss-certs plus nss-certs in operating-system packages causes problems

Previous Next

To reply to this bug, email your comments to 70926 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: bug-guix <at> gnu.org
Subject: Having default nss-certs plus nss-certs in operating-system
 packages causes problems
Date: Mon, 13 May 2024 22:38:29 +0100

[Message part 1 (text/plain, inline)]

I've seen this when updating systems, but it seems like something is
wrong with the handling of nss-certs.

I'm on a guix revision with nss-certs by default, and when I add
nss-certs to my system packages (to simulate not removing it when
upgrading), it breaks certificates (e.g. wget https://guix.gnu.org/
doesn't work).

My reading of the operating-system-packages code suggests that adding
nss-certs shouldn't have any effect, but this doesn't seem to be
working.

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 70926 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Christopher Baines <mail <at> cbaines.net>, 70926 <at> debbugs.gnu.org
Subject: Re: Having default nss-certs plus nss-certs in operating-system
 packages causes problems
Date: Tue, 14 May 2024 07:44:30 +0200

Am Montag, dem 13.05.2024 um 22:38 +0100 schrieb Christopher Baines:
> I've seen this when updating systems, but it seems like something is
> wrong with the handling of nss-certs.
> 
> I'm on a guix revision with nss-certs by default, and when I add
> nss-certs to my system packages (to simulate not removing it when
> upgrading), it breaks certificates (e.g. wget https://guix.gnu.org/
> doesn't work).
I can confirm this on three machines (two of my own, one from a
relative): Having nss-certs in the packages field unexpectedly breaks
all known certificates.

> My reading of the operating-system-packages code suggests that adding
> nss-certs shouldn't have any effect, but this doesn't seem to be
> working.
It would be really nice to detect the mismatching versions if it's
based on that.  IIUC we graft nss-certs now, so that we can hot-swap
stuff like pythons certifi package.  Is this use case broken by any
chance?

Cheers

Message #13 received at 70926-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: 70926-done <at> debbugs.gnu.org, Christopher Baines <mail <at> cbaines.net>
Subject: Re: bug#70926: Having default nss-certs plus nss-certs in
 operating-system packages causes problems
Date: Wed, 15 May 2024 23:02:27 -0400

Hello,

Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:

> Am Montag, dem 13.05.2024 um 22:38 +0100 schrieb Christopher Baines:
>> I've seen this when updating systems, but it seems like something is
>> wrong with the handling of nss-certs.
>> 
>> I'm on a guix revision with nss-certs by default, and when I add
>> nss-certs to my system packages (to simulate not removing it when
>> upgrading), it breaks certificates (e.g. wget https://guix.gnu.org/
>> doesn't work).
> I can confirm this on three machines (two of my own, one from a
> relative): Having nss-certs in the packages field unexpectedly breaks
> all known certificates.
>
>> My reading of the operating-system-packages code suggests that adding
>> nss-certs shouldn't have any effect, but this doesn't seem to be
>> working.
> It would be really nice to detect the mismatching versions if it's
> based on that.  IIUC we graft nss-certs now, so that we can hot-swap
> stuff like pythons certifi package.  Is this use case broken by any
> chance?

Apparently having multiple nss-certs of the same version is no problem
(they get deduped later).  The original problem would thus only exist
when there are multiple versions of nss-certs listed in packages, as
could happen for installer-generated configs that use
'(specification->package "nss-certs"), which would pick the latest
version and clash with the one in %base-packages.

My code could call delete even in the first case, which would clear
*all* nss-certs because they were the same object.  That's now guarded
against in 35ae95061e1b843e1df069693177519f22f9a16d ("system: Do not
delete all nss-certs packages when they are the same object."), which
I've just pushed.

Closing.

-- 
Thanks,
Maxim

Message #16 received at 70926-done <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 70926-done <at> debbugs.gnu.org,
 Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: Re: bug#70926: Having default nss-certs plus nss-certs in
 operating-system packages causes problems
Date: Mon, 20 May 2024 10:39:42 +0100

[Message part 1 (text/plain, inline)]

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Hello,
>
> Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
>
>> Am Montag, dem 13.05.2024 um 22:38 +0100 schrieb Christopher Baines:
>>> I've seen this when updating systems, but it seems like something is
>>> wrong with the handling of nss-certs.
>>> 
>>> I'm on a guix revision with nss-certs by default, and when I add
>>> nss-certs to my system packages (to simulate not removing it when
>>> upgrading), it breaks certificates (e.g. wget https://guix.gnu.org/
>>> doesn't work).
>> I can confirm this on three machines (two of my own, one from a
>> relative): Having nss-certs in the packages field unexpectedly breaks
>> all known certificates.
>>
>>> My reading of the operating-system-packages code suggests that adding
>>> nss-certs shouldn't have any effect, but this doesn't seem to be
>>> working.
>> It would be really nice to detect the mismatching versions if it's
>> based on that.  IIUC we graft nss-certs now, so that we can hot-swap
>> stuff like pythons certifi package.  Is this use case broken by any
>> chance?
>
> Apparently having multiple nss-certs of the same version is no problem
> (they get deduped later).  The original problem would thus only exist
> when there are multiple versions of nss-certs listed in packages, as
> could happen for installer-generated configs that use
> '(specification->package "nss-certs"), which would pick the latest
> version and clash with the one in %base-packages.
>
> My code could call delete even in the first case, which would clear
> *all* nss-certs because they were the same object.  That's now guarded
> against in 35ae95061e1b843e1df069693177519f22f9a16d ("system: Do not
> delete all nss-certs packages when they are the same object."), which
> I've just pushed.

Great, thanks for fixing this Maxim!

Chris

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.