Lack of detached signatures

Lack of detached signatures

[Joseph Parmelee]

Hello all:

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.  Just a crypto
hash by itself, however strong, does not protect against man-in-the-middle
attacks.

Joseph

Re: Lack of detached signatures

[Junio C Hamano]

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.

Re: Lack of detached signatures

[Michael Witten]

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?

RE: Lack of detached signatures

[Olsen, Alan R]

[Sorry for the top posting. Outlook is evil.]

Detached signatures are created with gpg, not git.

What I would like to see in git would be signed commits. I have looked 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.)

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

RE: Lack of detached signatures

[Carlos Martín Nieto]

[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]

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+ا\x17ܨ}Ơz&j:+v\azZ++zfh~iz\x1ew?&)ߢ^[f



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

RE: Lack of detached signatures

[Joseph Parmelee]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3778 bytes --]


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@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+?\x17?}?z&j:+v\azZ++zfh~iz\x1ew?&)?^[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.

Re: Lack of detached signatures

[Junio C Hamano]

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.

Re: Lack of detached signatures

[Michael Witten]

On Wed, Sep 28, 2011 at 16:45, Junio C Hamano <gitster@pobox.com> wrote:

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

You are parroting Linus's drivel.

If we get to the point where we need the real Junio yelling:

  DO NOT USE IT!

then things went too far long before. In that case, my trust in you as
the maintainer would also take a hit; I expect you to use the
available technology to avoid such a situation.

Not everybody manages to read every [real] message of yours, so we
need to provide people with ways to check for themselves that the
sources that they have *locally* already are sound.

Re: Lack of detached signatures

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

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

This assumes you will see the message, so while it does solve simple
attacks like sending an email with a fake From: header to the actual
list, it does not solve more advanced attacks like compromising
kernel.org's mailing-list server to avoid delivering you the forged
email.

I know I'm being a little paranoid here, but given the recent events
with kernel.org, maybe we should be that paranoid :-(.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Lack of detached signatures

[Jeff King]

On Wed, Sep 28, 2011 at 09:45:21AM -0700, Junio C Hamano wrote:

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

Your suggestion above is something like an audit trail. It doesn't
prevent all mischief from happening, but after it happens and is
noticed, we can do some analysis, figuring out what happened and how to
clean up. Banks do this all the time with transactions.

At the same time, banks don't rely solely on an audit trail. They also
have up-front mechanisms, like passwords and ATM secrets, that help
prevent mischief from happening in the first place. And when they fail,
we fall back to the audit trail.

So having preventative mechanisms and audit mechanisms is not an
either-or situation. They complement each other; the strengths of one
can help when the other fails.

In this case, I think signed tarballs would be a nice complement to the
natural human audit trail. It can stop some attacks early, without
having to worry about the effort of analyzing and cleaning up after the
fact. Can the signature be wrong, or be checked improperly? Of course.
If you realize your machine has been hacked and your key stolen, then
you let everybody know and we fall back to auditing what has already
happened.

Each mechanism you put in place has a cost, of course. And it's worth
thinking about whether that cost is worthwhile. But it really is as easy
as running "gpg --detach-sign" when you upload a release, isn't it? You
already do something similar with the signed tags. So the cost of the
mechanism is quite low.

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

Right. In theory the master machine is harder to hack than the public
facing mirrors, but in this case it was not. Every link in the trust
chain introduces new possibilities for failure.

Given that git releases are all made by you, why not just sign them
locally with the same key you use to sign the release tags? It does mean
you have to generate and upload the .bz2 yourself[1], but is that really
that big a deal?

-Peff

[1] This is a minor nit, and probably not worth breaking away from the
way the rest of the world does it, but it is somewhat silly to sign the
compressed data. I couldn't care less about the exact bytes in the
compressed version; what I care about is the actual tar file. The
compression is just a transport.

Re: Lack of detached signatures

[Ted Ts'o]

On Wed, Sep 28, 2011 at 06:25:43PM -0400, Jeff King wrote:
> [1] This is a minor nit, and probably not worth breaking away from the
> way the rest of the world does it, but it is somewhat silly to sign the
> compressed data. I couldn't care less about the exact bytes in the
> compressed version; what I care about is the actual tar file. The
> compression is just a transport.

The worry I have is that many users don't check the GPG checksum files
as it is.  If they have to decompress the file, and then run gpg to
check the checksum, they might never get around to doing it.

That being said, I'm not sure I have a good solution.  One is to ship
the file without using detached signatures, and ship a foo.tar.gz.gpg
file, and force them to use GPG to unwrap the file before it can be
unpacked.  But users would yell and scream if we did that...

	       	     	   	    	   - Ted

Re: Lack of detached signatures

[Junio C Hamano]

Ted Ts'o <tytso@mit.edu> writes:

> On Wed, Sep 28, 2011 at 06:25:43PM -0400, Jeff King wrote:
>> [1] This is a minor nit, and probably not worth breaking away from the
>> way the rest of the world does it, but it is somewhat silly to sign the
>> compressed data. I couldn't care less about the exact bytes in the
>> compressed version; what I care about is the actual tar file. The
>> compression is just a transport.
>
> The worry I have is that many users don't check the GPG checksum files
> as it is.  If they have to decompress the file, and then run gpg to
> check the checksum, they might never get around to doing it.
>
> That being said, I'm not sure I have a good solution.  One is to ship
> the file without using detached signatures, and ship a foo.tar.gz.gpg
> file, and force them to use GPG to unwrap the file before it can be
> unpacked.  But users would yell and scream if we did that...

I suspect that letting GPG do the compression and shipping foo.tar.gpg
would work just fine as well, and it is somewhat a tempting response to a
_demand_ to sign materials we distribute. Of course, a nicer response to a
_request_ would be to give a detached signature ;-)

I understand that the automated GPG signature k.org used to use on the
master machine was primarily to protect the copies that the mirrors serve
from getting tampered after they leave the master machine. Do you happen
to know what the new policy will be? Will the developers who distribute
their snapshot tarballs from the site be GPG signing them themselves
before uploading? That would improve the situation (I suspect that there
were some people who misunderstood that these GPG signature were to
protect against break-in at the master machine), but at the same time, it
may create the chicken-and-egg bootstrapping problem if public keys of too
many people need to be published securely.

Re: Lack of detached signatures

[Ted Ts'o]

On Wed, Sep 28, 2011 at 05:28:53PM -0700, Junio C Hamano wrote:
> 
> I suspect that letting GPG do the compression and shipping foo.tar.gpg
> would work just fine as well, 

Good point.  If only "tar -xW foo.tar.gpg" automatically verified the
gpg signature, that would work really well indeed.  :-)

> I understand that the automated GPG signature k.org used to use on the
> master machine was primarily to protect the copies that the mirrors serve
> from getting tampered after they leave the master machine. Do you happen
> to know what the new policy will be? Will the developers who distribute
> their snapshot tarballs from the site be GPG signing them themselves
> before uploading?

This is still being negotiated.  Given that developers are starting to
sign their release tags (and of course Linus has been doing this
already), one of the things that I've proposed is that we support is
to have the developer do something like this:

git archive --format=tar -o e2fsprogs-1.41.12.tar v1.41.12
gzip -9n e2fsprogs-1.41.12.tar
gpg --sign --detach -a e2fsprogs-1.41.12.tar.gz

and then just uploading the tar.gz.gpg file, the URL for the git tree,
and the tag that the server should use do the extraction.

> That would improve the situation (I suspect that there
> were some people who misunderstood that these GPG signature were to
> protect against break-in at the master machine), but at the same time, it
> may create the chicken-and-egg bootstrapping problem if public keys of too
> many people need to be published securely.

We are in the process of bootstrapping a GPG web of trust.  Linus has
generated a new GPG key which has been signed by Peter Anvin, Dirk,
and myself.  We'll get a much richer set of cross signatures at the
Kernel Summit in Prague in a few months.

Also, there's a pretty good intersection between kernel developers and
the Debian web of trust; there's been some talk of using that as an
auxiliary bootstrap for isolated kernel developers in distant part of
the world.

					- Ted

Re: Lack of detached signatures

[Junio C Hamano]

Ted Ts'o <tytso@mit.edu> writes:

>> That would improve the situation (I suspect that there
>> were some people who misunderstood that these GPG signature were to
>> protect against break-in at the master machine), but at the same time, it
>> may create the chicken-and-egg bootstrapping problem if public keys of too
>> many people need to be published securely.
>
> We are in the process of bootstrapping a GPG web of trust.  Linus has
> generated a new GPG key which has been signed by Peter Anvin, Dirk,
> and myself.  We'll get a much richer set of cross signatures at the
> Kernel Summit in Prague in a few months.

I was actually more worried about helping consumers convince themselves
that thusly signed keys indeed belong to producers like Linus, Peter,
etc. There are those who worry that DNS record to code.google.com/ for
them may point at an evil place to give them rogue download material.
"Here are the keys you can verify our trees with" message on the mailing
list, even with the message is signed with GPG, would not be satisfactory
to them.

Re: Lack of detached signatures

[Ted Ts'o]

On Wed, Sep 28, 2011 at 08:50:49PM -0700, Junio C Hamano wrote:
> 
> I was actually more worried about helping consumers convince themselves
> that thusly signed keys indeed belong to producers like Linus, Peter,
> etc. There are those who worry that DNS record to code.google.com/ for
> them may point at an evil place to give them rogue download material.
> "Here are the keys you can verify our trees with" message on the mailing
> list, even with the message is signed with GPG, would not be satisfactory
> to them.

What do you mean by "consumers" in this context?  Most end users don't
actually download tarballs from www.kernel.org or code.google.com!  :-)

If you mean developers at Linux distributions Red Hat, SuSE, or
Handset manufacturers such as Samsung, HTC, Motorola, etc., there will
be many of those reprsenatives at LinuxCon Europe and CELF (Consumer
Electronics Linux Forum) Europe conferences, which will be colocated
with the Kernel Summit in Prague.

If you are thinking of random developers located in far-flung places
of the world who don't have any contact with other Linux developers,
this is a previously unsolved problem.  There are links into the
developing Kernel GPG tree that are signed by the GPG web trust used
by Debian, OpenSuSE, and (soon) Fedora.  Given that people generally
have to trust one or more of those web of trusts, that's the best we
can do, at least as far as I know.  If you can suggest something
better, please let me know!


						- Ted

Re: Lack of detached signatures

[Sverre Rabbelier]

Heya,

On Thu, Sep 29, 2011 at 15:18, Ted Ts'o <tytso@mit.edu> wrote:
> Handset manufacturers such as Samsung, HTC, Motorola, etc., there will
> be many of those reprsenatives at LinuxCon Europe and CELF (Consumer
> Electronics Linux Forum) Europe conferences, which will be colocated
> with the Kernel Summit in Prague.
>
> If you are thinking of random developers located in far-flung places
> of the world who don't have any contact with other Linux developers,
> this is a previously unsolved problem.  There are links into the
> developing Kernel GPG tree that are signed by the GPG web trust used
> by Debian, OpenSuSE, and (soon) Fedora.  Given that people generally
> have to trust one or more of those web of trusts, that's the best we
> can do, at least as far as I know.  If you can suggest something
> better, please let me know!

This all sounds very interesting. Where is this discussion on a new
web of trust taking place? The kernel mailing list? Do you have a
message-id / gmane.org link for me to read more about this perhaps?

-- 
Cheers,

Sverre Rabbelier

Re: Lack of detached signatures

[Ted Ts'o]

On Thu, Sep 29, 2011 at 04:40:54PM +0200, Sverre Rabbelier wrote:
> 
> This all sounds very interesting. Where is this discussion on a new
> web of trust taking place? The kernel mailing list? Do you have a
> message-id / gmane.org link for me to read more about this perhaps?

It's been taking place on private e-mails and on conference calls
amongst those of us who have been organizing the kernel.org recovery
efforts.  There will be a more detailed discussion and a GPG key
signing party that I will be organizing at the upcoming kernel summit
meeting in Prague.

What are your concerns?

					- Ted

Re: Lack of detached signatures

[Sverre Rabbelier]

Heya,

On Thu, Sep 29, 2011 at 16:50, Ted Ts'o <tytso@mit.edu> wrote:
> On Thu, Sep 29, 2011 at 04:40:54PM +0200, Sverre Rabbelier wrote:
>>
>> This all sounds very interesting. Where is this discussion on a new
>> web of trust taking place? The kernel mailing list? Do you have a
>> message-id / gmane.org link for me to read more about this perhaps?
>
> It's been taking place on private e-mails and on conference calls
> amongst those of us who have been organizing the kernel.org recovery
> efforts.  There will be a more detailed discussion and a GPG key
> signing party that I will be organizing at the upcoming kernel summit
> meeting in Prague.
>
> What are your concerns?

Not concerned at all. I just would have enjoyed listening in to those
more knowledgeable than me discussing security and trust :).

-- 
Cheers,

Sverre Rabbelier

Re: Lack of detached signatures

[Joseph Parmelee]

On Thu, 29 Sep 2011, Ted Ts'o wrote:

> On Wed, Sep 28, 2011 at 08:50:49PM -0700, Junio C Hamano wrote:
>>
>> I was actually more worried about helping consumers convince themselves
>> that thusly signed keys indeed belong to producers like Linus, Peter,
>> etc. There are those who worry that DNS record to code.google.com/ for
>> them may point at an evil place to give them rogue download material.
>> "Here are the keys you can verify our trees with" message on the mailing
>> list, even with the message is signed with GPG, would not be satisfactory
>> to them.
>
> What do you mean by "consumers" in this context?  Most end users don't
> actually download tarballs from www.kernel.org or code.google.com!  :-)
>
> If you mean developers at Linux distributions Red Hat, SuSE, or
> Handset manufacturers such as Samsung, HTC, Motorola, etc., there will
> be many of those reprsenatives at LinuxCon Europe and CELF (Consumer
> Electronics Linux Forum) Europe conferences, which will be colocated
> with the Kernel Summit in Prague.
>
> If you are thinking of random developers located in far-flung places
> of the world who don't have any contact with other Linux developers,
> this is a previously unsolved problem.  There are links into the
> developing Kernel GPG tree that are signed by the GPG web trust used
> by Debian, OpenSuSE, and (soon) Fedora.  Given that people generally
> have to trust one or more of those web of trusts, that's the best we
> can do, at least as far as I know.  If you can suggest something
> better, please let me know!
>
>
> 						- Ted
>

Also included is distro developers that gen custom distros for limited
corporate use on specific hardware, and anyone else that is sufficiently
concerned about security and/or survivability that they prefer/need to build
from the upstream source.

As far as accepting public keys, a key obtained from the key servers and
signed by others, while not perfect, is vastly superior to nothing at all. 
I am located in the mountains of Costa Rica.  Over the years I have
collected a fair number of public keys making it very difficult for bad guys
to fake both a public key and all the signatures too, even though I can't
travel to a "key signing party" which would of course be better.

Even if we have to change all the keys now its going to be risky but still
vastly better than nothing.  I would hope that a new key would be signed by
an existing valid private key as well as newly issued keys.  This would
reassure people like me who have a substantial stash of old but valid public
keys, while at the same time thwarting bad guys who can fake only those old
signatures for which they have stolen valid private keys.

Joseph

Re: Lack of detached signatures

[Joseph Parmelee]

On Wed, 28 Sep 2011, Ted Ts'o wrote:

> On Wed, Sep 28, 2011 at 06:25:43PM -0400, Jeff King wrote:
>> [1] This is a minor nit, and probably not worth breaking away from the
>> way the rest of the world does it, but it is somewhat silly to sign the
>> compressed data. I couldn't care less about the exact bytes in the
>> compressed version; what I care about is the actual tar file. The
>> compression is just a transport.
>
> The worry I have is that many users don't check the GPG checksum files
> as it is.  If they have to decompress the file, and then run gpg to
> check the checksum, they might never get around to doing it.
>
> That being said, I'm not sure I have a good solution.  One is to ship
> the file without using detached signatures, and ship a foo.tar.gz.gpg
> file, and force them to use GPG to unwrap the file before it can be
> unpacked.  But users would yell and scream if we did that...
>
> 	       	     	   	    	   - Ted
>


Or you could just provide detached signatures for the compressed tarballs
like they have been doing for years at kernel.org (and many other sites). 
If tarball.tar.bz2 has a detached signature tarball.tar.bz2.sig, just
download them both and:

   gpg --verify tarball.tar.gz.sig

To argue that some people don't avail themselves of this feature is no
excuse for not providing it for those of us who consider it vital.  The
break in at k.o is no excuse for dropping this very sensible policy which
has protected us for years.  Just change the signing key and continue as
before.

Re: Lack of detached signatures

[Jeff King]

On Wed, Sep 28, 2011 at 07:09:58PM -0400, Ted Ts'o wrote:

> On Wed, Sep 28, 2011 at 06:25:43PM -0400, Jeff King wrote:
> > [1] This is a minor nit, and probably not worth breaking away from the
> > way the rest of the world does it, but it is somewhat silly to sign the
> > compressed data. I couldn't care less about the exact bytes in the
> > compressed version; what I care about is the actual tar file. The
> > compression is just a transport.
> 
> The worry I have is that many users don't check the GPG checksum files
> as it is.  If they have to decompress the file, and then run gpg to
> check the checksum, they might never get around to doing it.

It shouldn't really be any more cumbersome. But at the same time, it's
different than the way everyone else does it, so any minor convenience
we get is probably nullified by simply confusing anybody.

I wonder how many people actually check gpg checksums on downloaded
files. I don't usually. But I do expect something like a package manager
building from upstream source (e.g., freebsd-style ports, or distro
packagers pulling a new upstream) to bother to check it.

> That being said, I'm not sure I have a good solution.  One is to ship
> the file without using detached signatures, and ship a foo.tar.gz.gpg
> file, and force them to use GPG to unwrap the file before it can be
> unpacked.  But users would yell and scream if we did that...

And rightly so. I mentioned the cost of implementing the mechanism
before. If it's just "Junio runs gpg and throws the detached signature
up on the ftp site", it's not a big deal. But if it's "you can't
download and install git until you have gpg installed", that is raising
the bar quite a bit.

It should be the recipient's decision how much they want to trust the
data. We would just be helping them out by providing more information.

-Peff

RE: Lack of detached signatures

[Olsen, Alan R]

[Sorry for the top posting. Fscking Outlook demands it.]

The value of detached signatures is not that the users catch a hacked version, it is that the automated build bots catch the hacked version.  There was a server compromised a number of years back that was not caught by users, but by the Gentoo build bot.

What I would eventually like to see is a similar way to check an existing git tree and make sure all the commits authenticate and have not been tampered with.  That is a harder problem since the actual patch can change during a merge. (Having cryptographic sign-offs would be helpful as well. I have seen a few cases internally where the signoffs were for bogus e-mail addresses that got generated by automated tools, as well as patches that got altered after the sign-off.)

-----Original Message-----
From: Ted Ts'o [mailto:tytso@mit.edu] 
Sent: Wednesday, September 28, 2011 4:10 PM
To: Jeff King
Cc: Junio C Hamano; Joseph Parmelee; Carlos Martín Nieto; Olsen, Alan R; Michael Witten; git@vger.kernel.org
Subject: Re: Lack of detached signatures

On Wed, Sep 28, 2011 at 06:25:43PM -0400, Jeff King wrote:
> [1] This is a minor nit, and probably not worth breaking away from the
> way the rest of the world does it, but it is somewhat silly to sign the
> compressed data. I couldn't care less about the exact bytes in the
> compressed version; what I care about is the actual tar file. The
> compression is just a transport.

The worry I have is that many users don't check the GPG checksum files
as it is.  If they have to decompress the file, and then run gpg to
check the checksum, they might never get around to doing it.

That being said, I'm not sure I have a good solution.  One is to ship
the file without using detached signatures, and ship a foo.tar.gz.gpg
file, and force them to use GPG to unwrap the file before it can be
unpacked.  But users would yell and scream if we did that...

	       	     	   	    	   - Ted

Re: Lack of detached signatures

[Joseph Parmelee]

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.

RE: Lack of detached signatures

[Ben Walton]

Excerpts from Olsen, Alan R's message of Wed Sep 28 00:17:54 -0400 2011:

Hi Alan,

> What I would like to see in git would be signed commits. I have
> looked 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.)

I'm presuming that your intent is an optional signature, not a forced
one, but for discussion, consider the monotone[1] dvcs that forces a
signature on every commit.

While interesting, it was quite heavy weight.  Their design was
complicated by the fact that they used their own pki solution instead
of relying on gpg (although they did integrate with gpg-agent).
Granting access to a new user meant sharing monotone-specific keys,
etc.  It's been my experience that ssh keys are challenging enough for
many people, and asking them to use gpg keys is just not going to fly
unless mandated from the higher-ups.

We used monotone here for about a year and the key requirements were
the biggest turn off to adoption.  Maybe using standard (gpg) tools
would have been less so, but for the most part, I don't think so.

In my (very humble) opinion, signed tags (or possibly the new signed
push certificates) are a much better solution to this.  They offer the
same guarantees as having every commit signed (trust of all commits
can be determined based on a signle signature) but leave daily
interactions much more light weight and flexible.

Thanks
-Ben

[1] http://monotone.ca
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302