Re: Securing the software distribution chain

[zimoun <zimon.toutoune@gmail.com>]

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