Re: Lack of detached signatures

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 28, 2011, 16:45 UTC
Message-ID: <7v1uv01uqm.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.LNX.2.00.1109280555460.25187@bruno>

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

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.

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