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.touto...@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’.
