Dear, On Mon, 27 Jul 2020 at 14:54, Ludovic Courtès <l...@gnu.org> wrote:
> Of course we could have additional tools to make use of that info, say > ‘guix build -S --authenticate’ or something. But that would still be > optional. What do you mean? The command "guix build -S" returns the tarball (where non-free code is removed). Therefore, this hypothetical and optional "--authenticate" would authenticate against who? The user who runs the command; well I am not sure it is an useful use-case. The build farm which would authenticate substitutes, but the commits are already signed so it would not add some trust > Note that ‘guix refresh -u’ and ‘guix import gnu’ (and maybe other > importers too?) take care of tarball authentication already. ‘guix > download’ could share part of the mechanism. I agree it would be nice. [...] > On a related note, and perhaps that’s what you mean by “parts of the > artifact changing”, see the discussion on authenticating source code > archived at Software Heritage: > > https://sympa.inria.fr/sympa/arc/swh-devel/2016-07/msg00009.html > https://forge.softwareheritage.org/T2430#46046 > https://issues.guix.gnu.org/42162#4 > > Content-addressing is nice, but not very useful if each tool (IPFS, SWH, > Git, Guix) has its own way to address content… Well, the challenge seems here. First transition from url-fetch signed tarballs to authenticable content-addressed code such as signed git-fetch and second be able to bridge the different address contents. Or let fall in the trap [1]. :-) 1: https://xkcd.com/927/ All the best, simon
