Hello, Liliana Marie Prikler <liliana.prik...@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
