[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Checking signatures on source tarballs

From: Ludovic Courtès
Subject: Re: Checking signatures on source tarballs
Date: Sun, 11 Oct 2015 19:44:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Mark H Weaver <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>> What you suggest would be perfect but, if I understand it correctly,
>> it’s far from reality.
> What exactly is far from reality?  I did not speak about what _is_, but
> rather about what we _should_ do to improve things.

Sorry, that was poorly worded.  What I meant to say is that the
practices of upstream developers are on average far more “sloppy” than
we, as downstream, would end up setting up.

A particular problem I see, is that we would end up maintaining a list
of authorized fingerprints when 90% of upstream developers do not
actually provide that information.

This is not to say we shouldn’t try.  Rather, what I’m saying is that we
should make sure we don’t over-engineer a solution whose benefits would,
in effect, be significantly limited by what upstream actually does.


> It seems to me that you're rejecting this proposal because you see that
> it's not yet practical to do the job perfectly.

I’m not rejecting the proposal.  My main concern is the implementation
of the proposal; I think it’s easy to over-engineer it, or end up with
something that doesn’t scale, or provides wrong assurance.

> In my view, it is enough that it would be a significant improvement
> over what we have now.  In my first message in this thread, I listed
> the following benefits:
> I wrote:
>> * If the packager downloaded a key belonging to a man-in-the-middle
>>   (quite possible given that we rarely have a validated chain of trust
>>   to the developer), then that bad key will be stored in our git repo
>>   for all to see, allowing someone to notice that it's the wrong key.

I agree that’s an improvement, because it provides an audit trail.

In practice it may still be hard to determine whether this is the
“wrong” key, because only upstream can tell.

>> * When the package is later updated, it will not be possible for a new
>>   man-in-the-middle attack to be made on us.  If a new signing key is
>>   used, we cannot fail to notice it.  It will raise a red flag and we
>>   can investigate.


>> * It would strongly encourage packagers to do these checks, and make it
>>   obvious to reviewers or users when the packager failed to do so.  It
>>   would also make it easy to find unsigned packages, so that we can
>>   encourage upstream to start signing the packages, at least for the
>>   most important ones.


> Do you disagree that my proposal would have these benefits?


So, how do we do this?  :-)

Something like
where the signature fields are optional?

Do we force signature checks as part of the derivation builds, or do we
make it off-line (say, in ‘guix lint’), or both?

How do we handle projects that maintain a list of authorized public
keys, like GNU, Tor, and


reply via email to

[Prev in Thread] Current Thread [Next in Thread]