Re: Checking signatures on source tarballs

[Ludovic Courtès]

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.

Agreed.

>> * 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.

Agreed.

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

No!

So, how do we do this?  :-)

Something like
<http://git.savannah.gnu.org/cgit/guix.git/tree/TODO?id=3476ded934dc0beab1801d7fcdcc37b5c17bbf01#n52>,
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 kernel.org?

Thanks,
Ludo’.