[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Securing the software distribution chain
From: |
zimoun |
Subject: |
Re: Securing the software distribution chain |
Date: |
Mon, 27 Jul 2020 20:13:39 +0200 |
Dear,
On Mon, 27 Jul 2020 at 14:54, Ludovic Courtès <ludo@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