RE: Lack of detached signatures
- From
- Joseph Parmelee <jparmele@wildbear.com>
- Date
- Sep 28, 2011, 12:36 UTC
- Message-ID
- <alpine.LNX.2.00.1109280555460.25187@bruno>
- In-Reply-To
- <1317195719.30267.4.camel@bee.lab.cmartin.tk>
On Wed, 28 Sep 2011, Carlos Martín Nieto wrote:
Show 54 quoted lines
> On Wed, 2011-09-28 at 04:17 +0000, Olsen, Alan R wrote:
>> [Sorry for the top posting. Outlook is evil.]
>>
>> Detached signatures are created with gpg, not git.
>
> Git delegates all the signing business to gpg.
>
>>
>> What I would like to see in git would be signed commits. I have looked
>
> Every single commit? That sounds very heavy. You might want to look at
> signed pushes (signed push certificates), which were discussed in the
> list some time the kernel.org intrusion.
>
> Due to the way git calculates the hash for each object, signing a tag
> means that you also sign every single commit up to that point (with all
> their tree and blob objects).
>
>> at what it would take to make it work, but I don't have all the
>> details worked out. (Certain merges and cherry-picks would not work
>> very well.)
>
> This is precisely because of the cryptographic hash that is used to make
> sure that history doesn't get changed.
>
> cmn
>
>>
>> -----Original Message-----
>> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Michael Witten
>> Sent: Tuesday, September 27, 2011 5:08 PM
>> To: Junio C Hamano
>> Cc: Joseph Parmelee; git@vger.kernel.org
>> Subject: Re: Lack of detached signatures
>>
>> On Wed, Sep 28, 2011 at 00:03, Junio C Hamano <gitster@pobox.com> wrote:
>>> Joseph Parmelee <jparmele@wildbear.com> writes:
>>>
>>>> Under the present circumstances, and particularly considering the
>>>> sensitivity of the git code itself, I would suggest that you implement
>>>> signed detached digital signatures on all release tarballs.
>>>
>>> Well, signed tags are essentially detached signatures. People can verify
>>> tarballs against them if they wanted to, although it is a bit cumbersome.
>>
>> Aren't tarballs used to get git on machines that don't yet have git?
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> NrybX?v^)?{.n+??}?z&j:+vzZ++zfh~iz w?&)?f
>
>
>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. That is my point: either produce signatures with the tarballs, or don't provide them at all and force users to clone the repository. Git itself provides internal crytopgraphic protection with its commit tags.
The stability of the head depends on the policies followed by the developers and cannot be known by users not intimately involved in the development. In any event if there is a tarball most users assume that it represents a more stable state of the repository than the head and they will tend to use it, even if they already have a version of the code, instead of cloning the repository directly.
Git, and its signing key, are high-value targets for the bad guys, even higher than the kernel itself. I hope you will give just a moment's thought to the damage that will be done if bad guys succeed in a DNS poisoning attack and succeed in passing off a phony git tarball with a back door in the git code itself to a major code project. Any code produced in a repository using that phony version of git can then itself be corrupted.
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 suspect that their signing key was not so lucky and needs to be changed. The situation now is really dangerous with various important projects scattered about, including git, which are being operated without proper consideration of security.