Re: Lack of detached signatures

[Joseph Parmelee <jparmele@wildbear.com>]

On Wed, 28 Sep 2011, Junio C Hamano wrote:

> Joseph Parmelee <jparmele@wildbear.com> writes:
>
>> There is confusion here between the repository and the tarball.  Once you
>> have produced the tarball there is NO cryptographic protection against
>> forgeries unless you sign it with GPG.
>
> True.
>
> If I give you a URL http://code.google.com/p/git-core/downloads/list with
> checksums
>
>  $ sha1sum git-1.7.7.rc3.tar.gz
>  c6ba05a833cab49dd66dd1e252306e187effbf2b  git-1.7.7.rc3.tar.gz
>
> You either have to trust that code.google.com/ is not broken, or this
> message is coming from real Junio (provided if you can trust him in the
> first place).
>

How do I know that I am actually connected to code.google.com and not some
other site served up to me by a bogus proxy somewhere?

> BUT.
>
> The world is not so blank-and-white. Trust is ultimately among humans. If
> this message is not from the real Junio, don't you think you will hear
> something like "No, that c6ba05... is forgery, please don't use it!" from
> him, when he finds this message on the Git mailing list?  If he does not
> exercise diligence to even do that much, does he deserve your trust in the
> first place?
>
> GPG does add security (if you have the key) but you can do pretty well
> even without it in practice.
>

Nonsense.  There is a reason why responsible sites everywhere use detached
signatures on their release tarballs.


>> It is only because kernel.org exercised due diligence in the production of
>> tags and signatures on all their tarballs that the kernel code itself
>> withstood their recent intrusion....
>
> I do not think that is true at all. Developers just dropped *.tar.gz on a
> 'master' machine, and left the rest to a cron job that reflates the
> tarball into *.tar.bz2, sign both using a GPG key, and mirror them to the
> public-facing machines 'www'.
>
> Somebody who had access to the 'master' machine could add a new tarball
> and have it go thru the same exact process, getting signed by the cron.
>

The "cron job" provided the passphrase for the signing as well instead of
requiring a human to authorize the transaction by providing the passphrase
or by some other means?  I suspect not.  Have you actually used GPG to sign
something?

And even if that egregious error (no human authorization) had been made,
there is the matter of the secret signing key.  Of course if the bad guys
have that (and the passphrase) then they have everything and can readily
prepare fraudulent packages.  But without a detached signature you are
allowing them to do it even without going to the bother of stealing the
secret key and breaking/stealing the passphrase.  Without a dual key
signature, you are providing ABSOLUTELY NO protection against
man-in-the-middle attacks that you will never know occurred, but which will
nevertheless (rightfully) reflect on your project.  To just assert that "you
can do pretty well even without it in practice" is just plain irresponsible
and convinces me not to update our copies of git until it returns to
kernel.org and to administrators that understand the situation.