Re: Checking signatures on source tarballs

[Mark H Weaver]

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.

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

Tor publishes a list, but I agree that it's rare.  So, in practice, we
would populate the list of authorized signing keys from the *.sig files
we find.  So, we'd replace the current practice of "trust on first file
download" with "trust on first key download for each new signing key".
It's obviously not perfect, but it's better than what we have now:

* There would be fewer opportunities for MiTM attacks, because typically
  signing keys change less frequently than new upstream releases are
  made.

* We have better tools and practices for verifying the authenticity of
  GPG key fingerprints, e.g. key signing parties, the web of trust, key
  fingerprints printed on business cards, etc.

* I expect that people will be more motivated to make an effort to
  verify the set of authorized signing key fingerprints.  Speaking for
  myself, I would consider it well worth my time to walk up to an
  upstream developer at a conference and ask them which keys are
  authorized to sign their releases, and to get copies of the key
  fingerprints.  However, if I asked them instead for the SHA256 hash of
  their latest release, they'd probably look at me funny.  They'd be
  unlikely to have that information handy, and frankly it would be a bad
  approach because we'd have to do it all over again for their next
  release.

It seems to me that you're rejecting this proposal because you see that
it's not yet practical to do the job perfectly.  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.
> 
> * 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.

Do you disagree that my proposal would have these benefits?

     Thanks,
       Mark