Re: Checking signatures on source tarballs

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

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> 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?
>
> 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.

I agree with the goals.  I’m just wondering how this can be achieved in
practice in a way that scales.

I would suggest starting with GNU, because it’s easier.  If we manage to
get something that works and scales to all of GNU, then let’s extend it.

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

Not if the package is updated by the same person that retrieved the key
initially (similar to TOFU with SSH.)

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

How do we know which key is authorized for which package?

Even for GNU, we’d have to ask the FSF, and obviously the set of
authorized keys for each package keeps changing.  So we’d need the FSF
to provide us with a database/server to answer questions such as “which
public keys could sign for GNU Foo at this date?” in a secure way.

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

Sure, I agree.  But that’s what we have.

When I download a package, the best I can do is to download its .sig and
check it, optionally adding the corresponding public key to my keyring
if it’s missing.  And that’s it.

There’s a handful of packages for which I know personally the person who
uploads tarballs and their associated key.  For the rest, I just have to
trust the .sig to originate from an “authorized person”.

What you suggest would be perfect but, if I understand it correctly,
it’s far from reality.  There’s not a single project I know of that
publishes the list of public keys authorized to sign its tarballs.  Even
if they did, we’d need a way to authenticate that list.

Does that make sense?  Sounds very tricky to me!

Thanks,
Ludo’.