Re: Lack of detached signatures

From: Joseph Parmelee <jparmele@wildbear.com>
Date: Sep 28, 2011, 22:40 UTC
Message-ID: <alpine.LNX.2.00.1109281536540.25187@bruno>
In-Reply-To: <7v1uv01uqm.fsf@alter.siamese.dyndns.org>

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

Show 18 quoted lines

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

Show 12 quoted lines

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

Show 12 quoted lines

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