GNU bug report logs - #41908
guix time-machine fails; XXXX is not related to introductory commit of channel 'guix'

Previous Next

Full log

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 41908 <at> debbugs.gnu.org, Marius Bakke <marius <at> gnu.org>,
 Jan Nieuwenhuizen <janneke <at> gnu.org>
Subject: Re: bug#41908: guix time-machine fails;
 XXXX is not related to introductory commit of channel 'guix'
Date: Sat, 20 Jun 2020 12:40:49 +0200

Hi,

Ah yes, what you observed is interesting.  If you first travel to a
current-ish commit, it gets properly authenticated and cached.

From then on, since 36640207c9543e48cd6daa92930f023f80065a5d is in the
closure of the commit you just pulled, it’s authenticated, and you can
travel back to it.  It makes perfect sense.

Conversely, if you try to go directly to
36640207c9543e48cd6daa92930f023f80065a5d (e.g., with an empty cache),
all we can say is that we can’t authenticate it because it’s unrelated
to the introductory commit.

So it’s logical, even if surprising.  It also means that the problem
sort of “goes away” by itself.

zimoun <zimon.toutoune <at> gmail.com> skribis:

> BTW, from a security perspective, it is easy to cheat by removing some
> commits so the file ~/.cache/guix/authentication/channels/guix should be
> protected: read-only and only writable by the daemon.

It’s 600 of course.  What we could do is ignore it if it’s not 600 when
we open it.

Crucially: we cannot and should not restrict what the user can do for
the sake of security.  Users can pass ‘--disable-authentication’, they
can run binaries taken from the net, whatever; it’s their machine.

Thanks,
Ludo’.

Previous Next

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