GNU bug report logs - #67707
Fresh installation leaks details about ISO build environment

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 67707 in the body.
You can then email your comments to 67707 AT debbugs.gnu.org in the normal way.

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

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

From: Ludovic Courtès <ludovic.courtes <at> inria.fr>
To: bug-guix <at> gnu.org
Subject: Fresh installation leaks details about ISO build environment
Date: Fri, 08 Dec 2023 14:11:02 +0100

On a fresh installation of 1.4.0, we get:

--8<---------------cut here---------------start------------->8---
# guix system describe
Génération 1    08 déc. 2023 10:39:47   (actuelle)
  nom de fichier : /var/guix/profiles/system-1-link
  nom de fichier canonique : /gnu/store/d8g35zgpcg0k42jlxi3pda59nx3cgmhl-system
  étiquette : GNU with Linux-Libre 6.0.10
  chargeur de démarrage : grub
  périphérique racine : UUID : d17c4651-b142-4802-9d70-b018ee72c58e
  noyau : /gnu/store/3qdad0k7wvwl09wah246q7fvsb1hbr0x-linux-libre-6.0.10/bzImage
  canaux :
    guix:
      URL du dépôt : /home/ludo/src/guix/+version-1.4.0/
      branche : version-1.4.0
      commit : 989a3916dc8967bcb7275f10452f89bc6c3389cc
  fichier de configuration : /gnu/store/ram19r21j1rp0pfkdadmi3a6jp24fy36-configuration.scm
--8<---------------cut here---------------end--------------->8---

Oops!

That the URL is wrong doesn’t have any impact because it’s not used by
‘guix pull’ or anything, but it’s obviously not great.

Ludo’.

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

From: Rutherther <rutherther <at> ditigal.xyz>
To: 67707 <at> debbugs.gnu.org
Cc: Ludovic Courtès <ludovic.courtes <at> inria.fr>,
 Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: Fresh installation leaks details about ISO build environment
Date: Thu, 01 May 2025 14:47:12 +0200

Hi Ludo',

> That the URL is wrong doesn’t have any impact because it’s not used by
> ‘guix pull’ or anything, but it’s obviously not great.

this is not exactly true. It might be used, by the forward update check
on guix system reconfigure.
When the user hasn't pulled yet, they don't have any checkout, and a new
one is being created by looking at the folder
/home/ludo/src/guix/version/... That will end up with an error.

Maybe the installation-os should not use (current-guix) as that can lead
to issues like this? Could we instead just detect the commit and change
the url to the savannah/codeberg one?
Or will it just be ensured next time that the channels used to build it
point to the hosting url and not at a local one?

Regards
Rutherther

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

From: Ludovic Courtès <ludovic.courtes <at> inria.fr>
To: Rutherther <rutherther <at> ditigal.xyz>
Cc: 67707 <at> debbugs.gnu.org
Subject: Re: Fresh installation leaks details about ISO build environment
Date: Sat, 03 May 2025 18:23:15 +0200

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

References: <8734doh50v.fsf <at> ditigal.xyz>
User-Agent: mu4e 1.12.9; emacs 29.4
X-URL: https://people.bordeaux.inria.fr/lcourtes/
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
X-Revolutionary-Date: Quartidi 14 Floréal an 233 de la Révolution, jour du Chamérisier
Hello,

Rutherther <rutherther <at> ditigal.xyz> writes:

>> That the URL is wrong doesn’t have any impact because it’s not used by
>> ‘guix pull’ or anything, but it’s obviously not great.
>
> this is not exactly true. It might be used, by the forward update check
> on guix system reconfigure.
> When the user hasn't pulled yet, they don't have any checkout, and a new
> one is being created by looking at the folder
> /home/ludo/src/guix/version/... That will end up with an error.

True.

> Maybe the installation-os should not use (current-guix) as that can lead
> to issues like this? Could we instead just detect the commit and change
> the url to the savannah/codeberg one?
> Or will it just be ensured next time that the channels used to build it
> point to the hosting url and not at a local one?

I think so.  It should be as simple as this:

[Message part 2 (text/x-patch, inline)]

diff --git a/gnu/packages/package-management.scm b/gnu/packages/package-management.scm
index f0a9b39e25..46cf9b8512 100644
--- a/gnu/packages/package-management.scm
+++ b/gnu/packages/package-management.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2013-2024 Ludovic Courtès <ludo <at> gnu.org>
+;;; Copyright © 2013-2025 Ludovic Courtès <ludo <at> gnu.org>
 ;;; Copyright © 2015, 2017, 2020, 2021, 2022, 2023 Ricardo Wurmus <rekado <at> elephly.net>
 ;;; Copyright © 2017 Muriithi Frederick Muriuki <fredmanglis <at> gmail.com>
 ;;; Copyright © 2017, 2018 Oleg Pykhalov <go.wigust <at> gmail.com>
@@ -673,7 +673,8 @@ (define-public current-guix-package
             ((? channel? source)
              (package
                (inherit guix)
-               (source source)
+               (source (channel (inherit %default-guix-channel)
+                                (commit (channel-commit source))))
                (build-system channel-build-system)
                (inputs '())
                (native-inputs '())

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

Maybe there are cases where it’s not desirable (someone maintaining a
fork for example), but those are hypothetical edge cases.

WDYT?

Ludo’.
Date: Sat, 03 May 2025 18:23:14 +0200

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

From: Rutherther <rutherther <at> ditigal.xyz>
To: Ludovic Courtès <ludovic.courtes <at> inria.fr>
Cc: 67707 <at> debbugs.gnu.org
Subject: Re: Fresh installation leaks details about ISO build environment
Date: Sat, 03 May 2025 19:29:06 +0200

Hi Ludo,

Ludovic Courtès <ludovic.courtes <at> inria.fr> writes:

>
> Rutherther <rutherther <at> ditigal.xyz> writes:
>
>>> That the URL is wrong doesn’t have any impact because it’s not used by
>>> ‘guix pull’ or anything, but it’s obviously not great.
>>
>> this is not exactly true. It might be used, by the forward update check
>> on guix system reconfigure.
>> When the user hasn't pulled yet, they don't have any checkout, and a new
>> one is being created by looking at the folder
>> /home/ludo/src/guix/version/... That will end up with an error.
>
> True.
>
>> Maybe the installation-os should not use (current-guix) as that can lead
>> to issues like this? Could we instead just detect the commit and change
>> the url to the savannah/codeberg one?
>> Or will it just be ensured next time that the channels used to build it
>> point to the hosting url and not at a local one?
>
> I think so.  It should be as simple as this:
>
> diff --git a/gnu/packages/package-management.scm b/gnu/packages/package-management.scm
> index f0a9b39e25..46cf9b8512 100644
> --- a/gnu/packages/package-management.scm
> +++ b/gnu/packages/package-management.scm
> @@ -1,5 +1,5 @@
>  ;;; GNU Guix --- Functional package management for GNU
> -;;; Copyright © 2013-2024 Ludovic Courtès <ludo <at> gnu.org>
> +;;; Copyright © 2013-2025 Ludovic Courtès <ludo <at> gnu.org>
>  ;;; Copyright © 2015, 2017, 2020, 2021, 2022, 2023 Ricardo Wurmus <rekado <at> elephly.net>
>  ;;; Copyright © 2017 Muriithi Frederick Muriuki <fredmanglis <at> gmail.com>
>  ;;; Copyright © 2017, 2018 Oleg Pykhalov <go.wigust <at> gmail.com>
> @@ -673,7 +673,8 @@ (define-public current-guix-package
>              ((? channel? source)
>               (package
>                 (inherit guix)
> -               (source source)
> +               (source (channel (inherit %default-guix-channel)
> +                                (commit (channel-commit source))))
>                 (build-system channel-build-system)
>                 (inputs '())
>                 (native-inputs '())
>
> Maybe there are cases where it’s not desirable (someone maintaining a
> fork for example), but those are hypothetical edge cases.
>
> WDYT?

What I had in mind in the first place was replacing it just in the
install.scm, I didn't even think about changing it here.

I don't know, it feels a bit icky. This might be a good default - one
commonly uses (current-guix) for putting to virtual machines and you
don't want to end up with a local folder there. On the other hand,
there are cases when you do want the same channels and will get more
complicated with this change since one will have to get to know
repository->guix-channel and current-source-directory. What about making
two procedures, one that replaces with the default channel url and one
that doesn't?

Btw given the current state of things, I think this is quite 'dangerous'
as savannah is commonly failing, and people using (current-guix) end up
with it. This will hopefully be resolved in the future (either by switch
to codeberg or hopefully savannah will get better), but if this was
merged now I think it can cause more confusion.

Related to this issue, I am playing with an idea to introduce a new
option to guix system reconfigure that would skip the forward update
check. While it makes sense, especially lately it shows how problematic
it can get. There are people who cannot reconfigure because they have
savannah in their channels, they first have to pull from codeberg, and
even that is just a workaround (thankfully the forward update check will
use the repository you currently have configured instead of the older
one). This could happen even with other channels, not just guix.
Additionally it's also not so good for virtual machines where you
are just quickly testing something, and have to wait for a full checkout
fetch just because you decided to reconfigure. (maybe if the commit is
the same one as the old one there should be an additional check so that
nothing is fetched in the first place)

Thanks
Rutherther

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

From: Ludovic Courtès <ludovic.courtes <at> inria.fr>
To: Rutherther via Bug reports for GNU Guix <bug-guix <at> gnu.org>
Cc: 67707 <at> debbugs.gnu.org, Rutherther <rutherther <at> ditigal.xyz>
Subject: Re: bug#67707: Fresh installation leaks details about ISO build
 environment
Date: Mon, 05 May 2025 08:44:21 +0200

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

Hi,

Rutherther via Bug reports for GNU Guix <bug-guix <at> gnu.org> writes:

> What I had in mind in the first place was replacing it just in the
> install.scm, I didn't even think about changing it here.

Oh right, it’s probably best to change it there.  Something like this?

[Message part 2 (text/x-patch, inline)]

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index 15ea401f1c..50320a6698 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -35,6 +35,11 @@ (define-module (gnu system install)
   #:use-module ((guix packages) #:select (package-version supported-package?))
   #:use-module (guix platform)
   #:use-module (guix utils)
+  #:use-module (guix packages)
+  #:use-module ((guix channels)
+                #:select (%default-guix-channel
+                          channel
+                          channel-commit))
   #:use-module (gnu installer)
   #:use-module (gnu system locale)
   #:use-module (gnu services avahi)
@@ -392,7 +397,13 @@ (define* (%installation-services #:key (system (or (and=>
 
                      ;; Install and run the current Guix rather than an older
                      ;; snapshot.
-                     (guix (current-guix))))
+                     (guix (let ((guix (current-guix)))
+                             (package
+                               (inherit guix)
+                               (source (channel
+                                        (inherit %default-guix-channel)
+                                        (commit (channel-commit
+                                                 (package-source guix))))))))))
 
            ;; Start udev so that useful device nodes are available.
            ;; Use device-mapper rules for cryptsetup & co; enable the CRDA for

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

> Related to this issue, I am playing with an idea to introduce a new
> option to guix system reconfigure that would skip the forward update
> check. While it makes sense, especially lately it shows how problematic
> it can get. […]

I’m not sure I follow: even if one uses a mirror of Savannah, downgrade
prevention works fine.  Or are you referring to some other motivation?

Thanks,
Ludo’.

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

From: Rutherther <rutherther <at> ditigal.xyz>
To: Ludovic Courtès <ludovic.courtes <at> inria.fr>, Rutherther
 via Bug reports for GNU Guix <bug-guix <at> gnu.org>
Cc: 67707 <at> debbugs.gnu.org
Subject: Re: bug#67707: Fresh installation leaks details about ISO build
 environment
Date: Mon, 05 May 2025 18:48:04 +0200

Hi Ludo',

Ludovic Courtès <ludovic.courtes <at> inria.fr> writes:

> Hi,
>
> Rutherther via Bug reports for GNU Guix <bug-guix <at> gnu.org> writes:
>
>> What I had in mind in the first place was replacing it just in the
>> install.scm, I didn't even think about changing it here.
>
> Oh right, it’s probably best to change it there.  Something like this?

Yes, that is exactly what I had in mind. Btw I am wondering, is there a
policy on (not) updating the released iso?

>
> diff --git a/gnu/system/install.scm b/gnu/system/install.scm
> index 15ea401f1c..50320a6698 100644
> --- a/gnu/system/install.scm
> +++ b/gnu/system/install.scm
> @@ -35,6 +35,11 @@ (define-module (gnu system install)
>    #:use-module ((guix packages) #:select (package-version supported-package?))
>    #:use-module (guix platform)
>    #:use-module (guix utils)
> +  #:use-module (guix packages)
> +  #:use-module ((guix channels)
> +                #:select (%default-guix-channel
> +                          channel
> +                          channel-commit))
>    #:use-module (gnu installer)
>    #:use-module (gnu system locale)
>    #:use-module (gnu services avahi)
> @@ -392,7 +397,13 @@ (define* (%installation-services #:key (system (or (and=>
>  
>                       ;; Install and run the current Guix rather than an older
>                       ;; snapshot.
> -                     (guix (current-guix))))
> +                     (guix (let ((guix (current-guix)))
> +                             (package
> +                               (inherit guix)
> +                               (source (channel
> +                                        (inherit %default-guix-channel)
> +                                        (commit (channel-commit
> +                                                 (package-source guix))))))))))
>  
>             ;; Start udev so that useful device nodes are available.
>             ;; Use device-mapper rules for cryptsetup & co; enable the CRDA for
>
>
>> Related to this issue, I am playing with an idea to introduce a new
>> option to guix system reconfigure that would skip the forward update
>> check. While it makes sense, especially lately it shows how problematic
>> it can get. […]
>
> I’m not sure I follow: even if one uses a mirror of Savannah, downgrade
> prevention works fine.  Or are you referring to some other motivation?

I agree that the prevention works fine even with a mirror. What I wanted
to say is that sometimes it can't work. Like if a repository hosting is
down or you don't have internet connection. That is, if the checkout
(usually the one of root) doesn't contain the commit. Lately, it shows
because savannah is down very often. So one pulls successfully, but then
can't reconfigure, because savannah is down again. This is because root
has a separate checkout. Even if it didn't, if the checkouts are
removed, the user can't reconfigure if repo hosting is down.
This just feels like an unnecessary limitation - why not allow the user
to say: yes, this is a forward update, don't check,
ie. --disable-forward-update-check.

Workaround for savannah being down is to use a mirror. Thankfully the
check uses the currently configured source of the repository, so just
pulling out of the mirror, and then reconfiguring works.

Thanks
Rutherther

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

From: Ludovic Courtès <ludovic.courtes <at> inria.fr>
To: Rutherther via Bug reports for GNU Guix <bug-guix <at> gnu.org>
Cc: 67707-done <at> debbugs.gnu.org, Rutherther <rutherther <at> ditigal.xyz>
Subject: Re: bug#67707: Fresh installation leaks details about ISO build
 environment
Date: Tue, 06 May 2025 00:23:07 +0200

Hello,

Rutherther via Bug reports for GNU Guix <bug-guix <at> gnu.org> writes:

> Ludovic Courtès <ludovic.courtes <at> inria.fr> writes:

[...]

>> Oh right, it’s probably best to change it there.  Something like this?
>
> Yes, that is exactly what I had in mind.

OK, pushed as 94c9e53fa4b45e85c1664a9bab6aea0d5c3ac123.

I checked in ‘guix system vm gnu/system/install.scm’ that ‘guix
describe’ reports the right URL.

> Btw I am wondering, is there a policy on (not) updating the released
> iso?

Release artifacts in general are immutable.  But of course, we should
make a new release, that’s consensual.  :-)

>> I’m not sure I follow: even if one uses a mirror of Savannah, downgrade
>> prevention works fine.  Or are you referring to some other motivation?
>
> I agree that the prevention works fine even with a mirror. What I wanted
> to say is that sometimes it can't work. Like if a repository hosting is
> down or you don't have internet connection. That is, if the checkout
> (usually the one of root) doesn't contain the commit. Lately, it shows
> because savannah is down very often. So one pulls successfully, but then
> can't reconfigure, because savannah is down again. This is because root
> has a separate checkout.

Oh right, got it.  Hopefully this particular issue will vanish if we
decide to move to Codeberg (GCD 002).

> Even if it didn't, if the checkouts are removed, the user can't
> reconfigure if repo hosting is down.  This just feels like an
> unnecessary limitation - why not allow the user to say: yes, this is a
> forward update, don't check, ie. --disable-forward-update-check.

I was going to say that it’s called ‘--allow-downgrades’, but in fact
no, because that still clones/pulls to perform the check and emit a
warning (instead of an error).  Still, maybe it could catch clone/pull
errors?

Anyway, that’s for another bug report. :-)

Thanks,
Ludo’.

Previous Next

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