GNU bug report logs - #42162
gforge.inria.fr to be taken off-line in Dec. 2020

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 42162 <at> debbugs.gnu.org, Maurice Brémond <Maurice.Bremond <at> inria.fr>
Subject: bug#42162: Recovering source tarballs
Date: Wed, 22 Jul 2020 12:28:50 +0200

Hello!

zimoun <zimon.toutoune <at> gmail.com> skribis:

> On Tue, 21 Jul 2020 at 23:22, Ludovic Courtès <ludo <at> gnu.org> wrote:
>
>>>> >>   • If we no longer deal with tarballs but upstreams keep signing
>>>> >>     tarballs (not raw directory hashes), how can we authenticate our
>>>> >>     code after the fact?
>>>> >
>>>> > Does Guix automatically authenticate code using signed tarballs?
>>>>
>>>> Not automatically; packagers are supposed to authenticate code when they
>>>> add a package (‘guix refresh -u’ does that automatically).
>>>
>>> So I miss the point of having this authentication information in the
>>> future where upstream has disappeared.
>>
>> What I meant above, is that often, what we have is things like detached
>> signatures of raw tarballs, or documents referring to a tarball hash:
>>
>>   https://sympa.inria.fr/sympa/arc/swh-devel/2016-07/msg00009.html
>
> I still miss why it matters to store detached signature of raw tarballs.

I’m not saying we (Guix) should store signatures; I’m just saying that
developers typically sign raw tarballs.  It’s a general statement to
explain why storing or being able to reconstruct tarballs matters.

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.