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