Re: Distributed verification of release tarballs using Guix? (was Re: Releasing 2.2.5?)

[Mark H Weaver <mhw@netris.org>]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>> What would you think of releasing ‘stable-2.2’ as 2.2.5?
>>
>> I think it's a fine idea.
>
> Awesome.  We’ll have to update NEWS; I can give it a go, but if you
> could add bullet items for the things you’ve worked on, that’d be great.

Sure, I can take care of updating NEWS in the next day or two.

>>> It’s great if you can do it, Mark, but otherwise I can do it.
>>
>> Regrettably, Guile 2.2 has become too heavy to build on the only machine
>> in my possession that I have any trust in.  I don't have a machine that
>> I consider sufficiently trustworthy to produce build outputs for wider
>> distribution.  I'm not sure that any of us do.
>
> Note that “make dist” is rather inexpensive;

I assume it builds the prebuilt .go files, no?  That involves running
Guile's compiler, which is too heavy to run on my Yeeloong.

> “distcheck” is much more
> expensive though, but maybe avoidable for a minor release tarball.
>
>> To mitigate the risk that a compromised development machine could be
>> used to attack others, I propose that we adopt a practice of distributed
>> verification of release tarballs.  We would publish code that uses Guix
>> to produce the release tarball deterministically, and put out a call for
>> volunteers to generate the tarball and post signed declarations
>> containing the hash of the resulting tarball.  After we have received
>> several such declarations, we can sign and publish the official tarball.
>
> I don’t think this should block 2.2.5, but I think it’s an idea we
> should explore.

If you'd like to produce the 2.2.5 release in the traditional way,
that's fine with me.  I'm not comfortable doing it myself, though.

> One issue is that “make dist” is non-deterministic because the archive
> contains timestamps; I’m sure there of other sources of non-determinism
> though, because “make dist” was not designed with that in mind.

Right.  I suppose the right approach is to start a conversation with the
autotools developers.  In the meantime, I wonder if we could implement
our own deterministic version of "make dist" using Guix, and use that
instead.  Or perhaps it would be easier to use "make dist" and then
canonicalize the timestamps in the resulting tarball in a later step?

Thoughts?

> The non-source byproducts in release tarballs are: the pre-built .go
> files (which are optional), psyntax-pp.scm, and then Info files and all
> the autotools machinery.  Are these those you had in mind?

Yes, all of the above are potential security risks, except possibly for
the info files.

     Thanks!
       Mark