[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: Wed, 07 Oct 2015 14:06:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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?

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

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

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

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



reply via email to

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