Re: Checking signatures on source tarballs

[ludo@gnu.org (Ludovic Courtès)]

Mark H Weaver <mhw@netris.org> 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?

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.

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.

> 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?

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

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.

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

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

I have been thinking that ‘guix download’ could also automatically look
for .sig, .sign, and .asc files.  That’s easily done, and already an
improvement.

Thoughts?

Ludo’.