Re: Checking signatures on source tarballs

[Mark H Weaver]

address@hidden (Ludovic Courtès) writes:

> Mark H Weaver <address@hidden> skribis:
>
>> IMO, we should rather be going in the other direction, to formalize and
>> automate the checking of signatures.  IMO, our 'origin' objects should
>> include a set of fingerprints of acceptable GPG signing keys for that
>> package, as well as information on how to find the signature (in cases
>> where it cannot be guessed).
>
> I thought about it (it used to be in TODO), but this design has several
> problems.  One of them is that a keyring is needed if we are to verify
> signatures; where do we get it?

We can download the keys from a public keyserver.  However, checking
these signatures would be optional.  The sha256 hashes would continue to
be the authentication method used by default.  My goal is to improve
security by making it easy for others to independently verify the
signatures, and to keep an institutional knowledge of which keys are
authorized to sign for which packages.

> Another one is that, inherently, the daemon already handles integrity
> checks for fixed-output derivations, and authentication should really be
> made beforehand by the packager.

Agreed.  My proposal would not change that.

> Most of the time the authentication model is trust-on-first-download:
> The packager fetches upstream’s public key when they first download a
> tarball (so this particular phase is subject to MiTM), and subsequent
> downloads are checked against the key that’s already in the packager’s
> keyring.

Right, and every time the package is updated, that's another opportunity
for a MiTM attack.  My proposal would fix that problem.  It would also
allow MiTM attacks to be detected later, because the bad key would be
recorded in our git repository for all to see.

>> This would have several beneficial effects:
>>
>> * 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.
>
> So you’re suggesting to put the keyring under version control in a way,
> right?

No, I suggest storing only the key fingerprints.

> It sounds like a good idea, provided we at least the Git commits that
> add/modify the keyring are signed.  There’s a couple of issues: unless
> it can be stored in a plain-text format, it’ll be hard to audit changes
> that are made; it would quickly end up containing hundreds of public
> keys, so there’s a scalability issue: how do we keep it up-to-date? how
> do we decide who’s authorized to update it, etc.?

Indeed, storing the keyring would have many thorny issues, which is why
I didn't suggest it.

> First step would be to be able to do something meaningful with the GNU
> keyring.  It’s at ftp.gnu.org/gnu/gnu-keyring.gpg, but it’s currently
> unsigned; previous attempts to do something about it haven’t gone
> anywhere, but we could try again.

The GNU keyring could be useful but is not sufficient by itself, because
unless we record which keys are authorized to sign which packages, and
use that information during checking, the result is that _any_ key can
sign _any_ package, and the security of the entire system is reduced to
that of the weakest key on the GNU keyring.  This is not good.

>> * 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.
>
> As Andreas notes, outside of gnu.org, savannah.gnu.org, kernel.org, and
> a few others, it’s very frequent for packages to not be signed at all.

That's true, but I don't see why this argues against my proposal.

>> Also, our linter should download and check the signature, so that it's
>> easy for others to independently check the verification done by the
>> original packager.
>
> ‘guix import gnu’ and ‘guix refresh’ already do that, but only for GNU
> packages.

The current mechanism is very weak.  _Any_ key on your keyring could
sign the package, and it will be happy with that, thus reducing the
security of the check to that of the weakest key on your keyring.  Also,
each person who performs the check downloads the key from the keyserver
independently, typically without any verification that we haven't been
MiTM'd.

     Thanks,
       Mark