On Wed, 28 Sep 2011, Carlos Martín Nieto wrote:
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@xxxxxxxxxxxxxxx [mailto:git-owner@xxxxxxxxxxxxxxx] On Behalf Of Michael Witten
Sent: Tuesday, September 27, 2011 5:08 PM
To: Junio C Hamano
Cc: Joseph Parmelee; git@xxxxxxxxxxxxxxx
Subject: Re: Lack of detached signatures
On Wed, Sep 28, 2011 at 00:03, Junio C Hamano <gitster@xxxxxxxxx> wrote:
Joseph Parmelee <jparmele@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
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.