[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@xxxxxxx] 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@xxxxxxxxxxxxxxx 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 -- 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