{"thread":{"id":"28514","subject":"Lack of detached signatures","startedAt":"2011-09-27T23:48:46Z","lastAt":"2011-09-29T20:31:02Z","messageCount":24,"participants":["Joseph Parmelee","Junio C Hamano","Michael Witten","Olsen, Alan R","Carlos Martín Nieto","Matthieu Moy","Ben Walton","Jeff King","Ted Ts'o","Sverre Rabbelier"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"176369","messageId":"alpine.LNX.2.00.1109271742460.24832@bruno","threadId":"28514","inReplyTo":null,"subject":"Lack of detached signatures","fromName":"Joseph Parmelee","fromEmail":"jparmele@wildbear.com","sentAt":"2011-09-27T23:48:46Z","receivedAt":"2011-09-27T23:48:46Z","isPatch":false,"sender":{"key":"jparmele@wildbear.com","avatar":null},"body":"Hello all:\n\nUnder the present circumstances, and particularly considering the\nsensitivity of the git code itself, I would suggest that you implement\nsigned detached digital signatures on all release tarballs. Just a crypto\nhash by itself, however strong, does not protect against man-in-the-middle\nattacks.\n\nJoseph\n"},{"id":"176372","messageId":"7vty7xttxh.fsf@alter.siamese.dyndns.org","threadId":"28514","inReplyTo":"alpine.LNX.2.00.1109271742460.24832@bruno","subject":"Re: Lack of detached signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-28T00:03:06Z","receivedAt":"2011-09-28T00:03:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joseph Parmelee writes:\n\n> Under the present circumstances, and particularly considering the\n> sensitivity of the git code itself, I would suggest that you implement\n> signed detached digital signatures on all release tarballs.\n\nWell, signed tags are essentially detached signatures. People can verify\ntarballs against them if they wanted to, although it is a bit cumbersome.\n"},{"id":"176373","messageId":"CAMOZ1Bs2HW6e3V6sayVSm0NhC=0e5129ZR8YSGuZPnJw9H9TEA@mail.gmail.com","threadId":"28514","inReplyTo":"7vty7xttxh.fsf@alter.siamese.dyndns.org","subject":"Re: Lack of detached signatures","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-28T00:07:58Z","receivedAt":"2011-09-28T00:07:58Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Wed, Sep 28, 2011 at 00:03, Junio C Hamano wrote:\n> Joseph Parmelee writes:\n>\n>> Under the present circumstances, and particularly considering the\n>> sensitivity of the git code itself, I would suggest that you implement\n>> signed detached digital signatures on all release tarballs.\n>\n> Well, signed tags are essentially detached signatures. People can verify\n> tarballs against them if they wanted to, although it is a bit cumbersome.\n\nAren't tarballs used to get git on machines that don't yet have git?\n"},{"id":"176382","messageId":"4B2793BF110AAB47AB0EE7B90897038516F63A7C@ORSMSX101.amr.corp.intel.com","threadId":"28514","inReplyTo":"CAMOZ1Bs2HW6e3V6sayVSm0NhC=0e5129ZR8YSGuZPnJw9H9TEA@mail.gmail.com","subject":"RE: Lack of detached signatures","fromName":"Olsen, Alan R","fromEmail":"alan.r.olsen@intel.com","sentAt":"2011-09-28T04:17:54Z","receivedAt":"2011-09-28T04:17:54Z","isPatch":false,"sender":{"key":"alan.r.olsen@intel.com","avatar":null},"body":"[Sorry for the top posting. Outlook is evil.]\n\nDetached signatures are created with gpg, not git.\n\nWhat 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.)\n\n-----Original Message-----\nFrom: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Michael Witten\nSent: Tuesday, September 27, 2011 5:08 PM\nTo: Junio C Hamano\nCc: Joseph Parmelee; git@vger.kernel.org\nSubject: Re: Lack of detached signatures\n\nOn Wed, Sep 28, 2011 at 00:03, Junio C Hamano wrote:\n> Joseph Parmelee writes:\n>\n>> Under the present circumstances, and particularly considering the\n>> sensitivity of the git code itself, I would suggest that you implement\n>> signed detached digital signatures on all release tarballs.\n>\n> Well, signed tags are essentially detached signatures. People can verify\n> tarballs against them if they wanted to, although it is a bit cumbersome.\n\nAren't tarballs used to get git on machines that don't yet have git?\n--\nTo unsubscribe from this list: send the line \"unsubscribe git\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"176387","messageId":"1317195719.30267.4.camel@bee.lab.cmartin.tk","threadId":"28514","inReplyTo":"4B2793BF110AAB47AB0EE7B90897038516F63A7C@ORSMSX101.amr.corp.intel.com","subject":"RE: Lack of detached signatures","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-09-28T07:41:49Z","receivedAt":"2011-09-28T07:41:49Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Wed, 2011-09-28 at 04:17 +0000, Olsen, Alan R wrote:\n> [Sorry for the top posting. Outlook is evil.]\n> \n> Detached signatures are created with gpg, not git.\n\nGit delegates all the signing business to gpg.\n\n> \n> What I would like to see in git would be signed commits. I have looked\n\nEvery single commit? That sounds very heavy. You might want to look at\nsigned pushes (signed push certificates), which were discussed in the\nlist some time the kernel.org intrusion.\n\nDue to the way git calculates the hash for each object, signing a tag\nmeans that you also sign every single commit up to that point (with all\ntheir tree and blob objects).\n\n> at what it would take to make it work, but I don't have all the\n> details worked out. (Certain merges and cherry-picks would not work\n> very well.)\n\nThis is precisely because of the cryptographic hash that is used to make\nsure that history doesn't get changed.\n\n cmn\n\n> \n> -----Original Message-----\n> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Michael Witten\n> Sent: Tuesday, September 27, 2011 5:08 PM\n> To: Junio C Hamano\n> Cc: Joseph Parmelee; git@vger.kernel.org\n> Subject: Re: Lack of detached signatures\n> \n> On Wed, Sep 28, 2011 at 00:03, Junio C Hamano wrote:\n> > Joseph Parmelee writes:\n> >\n> >> Under the present circumstances, and particularly considering the\n> >> sensitivity of the git code itself, I would suggest that you implement\n> >> signed detached digital signatures on all release tarballs.\n> >\n> > Well, signed tags are essentially detached signatures. People can verify\n> > tarballs against them if they wanted to, although it is a bit cumbersome.\n> \n> Aren't tarballs used to get git on machines that don't yet have git?\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> NrybXǧv^)޺{.n+ا\u0017ܨ}Ơz&j:+v\u0007zZ++zfh~iz\u001ew?&)ߢ\u001bf\n\n\n"},{"id":"176398","messageId":"alpine.LNX.2.00.1109280555460.25187@bruno","threadId":"28514","inReplyTo":"1317195719.30267.4.camel@bee.lab.cmartin.tk","subject":"RE: Lack of detached signatures","fromName":"Joseph Parmelee","fromEmail":"jparmele@wildbear.com","sentAt":"2011-09-28T12:36:10Z","receivedAt":"2011-09-28T12:36:10Z","isPatch":false,"sender":{"key":"jparmele@wildbear.com","avatar":null},"body":"\nOn Wed, 28 Sep 2011, Carlos Martín Nieto wrote:\n\n> On Wed, 2011-09-28 at 04:17 +0000, Olsen, Alan R wrote:\n>> [Sorry for the top posting. Outlook is evil.]\n>>\n>> Detached signatures are created with gpg, not git.\n>\n> Git delegates all the signing business to gpg.\n>\n>>\n>> What I would like to see in git would be signed commits. I have looked\n>\n> Every single commit? That sounds very heavy. You might want to look at\n> signed pushes (signed push certificates), which were discussed in the\n> list some time the kernel.org intrusion.\n>\n> Due to the way git calculates the hash for each object, signing a tag\n> means that you also sign every single commit up to that point (with all\n> their tree and blob objects).\n>\n>> at what it would take to make it work, but I don't have all the\n>> details worked out. (Certain merges and cherry-picks would not work\n>> very well.)\n>\n> This is precisely because of the cryptographic hash that is used to make\n> sure that history doesn't get changed.\n>\n> cmn\n>\n>>\n>> -----Original Message-----\n>> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Michael Witten\n>> Sent: Tuesday, September 27, 2011 5:08 PM\n>> To: Junio C Hamano\n>> Cc: Joseph Parmelee; git@vger.kernel.org\n>> Subject: Re: Lack of detached signatures\n>>\n>> On Wed, Sep 28, 2011 at 00:03, Junio C Hamano wrote:\n>>> Joseph Parmelee writes:\n>>>\n>>>> Under the present circumstances, and particularly considering the\n>>>> sensitivity of the git code itself, I would suggest that you implement\n>>>> signed detached digital signatures on all release tarballs.\n>>>\n>>> Well, signed tags are essentially detached signatures. People can verify\n>>> tarballs against them if they wanted to, although it is a bit cumbersome.\n>>\n>> Aren't tarballs used to get git on machines that don't yet have git?\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>> NrybX?v^)?{.n+?\u0017?}?z&j:+v\u0007zZ++zfh~iz\u001ew?&)?\u001bf\n>\n>\n>\n\nThere is confusion here between the repository and the tarball. Once you\nhave produced the tarball there is NO cryptographic protection against\nforgeries unless you sign it with GPG. That is my point: either produce\nsignatures with the tarballs, or don't provide them at all and force users\nto clone the repository. Git itself provides internal crytopgraphic\nprotection with its commit tags.\n\nThe stability of the head depends on the policies followed by the developers\nand cannot be known by users not intimately involved in the development. In\nany event if there is a tarball most users assume that it represents a more\nstable state of the repository than the head and they will tend to use it,\neven if they already have a version of the code, instead of cloning the\nrepository directly.\n\nGit, and its signing key, are high-value targets for the bad guys, even\nhigher than the kernel itself. I hope you will give just a moment's thought\nto the damage that will be done if bad guys succeed in a DNS poisoning\nattack and succeed in passing off a phony git tarball with a back door in\nthe git code itself to a major code project. Any code produced in a\nrepository using that phony version of git can then itself be corrupted.\n\nIt is only because kernel.org exercised due diligence in the production of\ntags and signatures on all their tarballs that the kernel code itself\nwithstood their recent intrusion. I suspect that their signing key was not\nso lucky and needs to be changed. The situation now is really dangerous\nwith various important projects scattered about, including git, which are\nbeing operated without proper consideration of security."},{"id":"176433","messageId":"7v1uv01uqm.fsf@alter.siamese.dyndns.org","threadId":"28514","inReplyTo":"alpine.LNX.2.00.1109280555460.25187@bruno","subject":"Re: Lack of detached signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-28T16:45:21Z","receivedAt":"2011-09-28T16:45:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joseph Parmelee writes:\n\n> There is confusion here between the repository and the tarball. Once you\n> have produced the tarball there is NO cryptographic protection against\n> forgeries unless you sign it with GPG.\n\nTrue.\n\nIf I give you a URL http://code.google.com/p/git-core/downloads/list with\nchecksums\n\n $ sha1sum git-1.7.7.rc3.tar.gz\n c6ba05a833cab49dd66dd1e252306e187effbf2b git-1.7.7.rc3.tar.gz\n\nYou either have to trust that code.google.com/ is not broken, or this\nmessage is coming from real Junio (provided if you can trust him in the\nfirst place).\n\nBUT.\n\nThe world is not so blank-and-white. Trust is ultimately among humans. If\nthis message is not from the real Junio, don't you think you will hear\nsomething like \"No, that c6ba05... is forgery, please don't use it!\" from\nhim, when he finds this message on the Git mailing list? If he does not\nexercise diligence to even do that much, does he deserve your trust in the\nfirst place?\n\nGPG does add security (if you have the key) but you can do pretty well\neven without it in practice.\n\n> It is only because kernel.org exercised due diligence in the production of\n> tags and signatures on all their tarballs that the kernel code itself\n> withstood their recent intrusion....\n\nI do not think that is true at all. Developers just dropped *.tar.gz on a\n'master' machine, and left the rest to a cron job that reflates the\ntarball into *.tar.bz2, sign both using a GPG key, and mirror them to the\npublic-facing machines 'www'.\n\nSomebody who had access to the 'master' machine could add a new tarball\nand have it go thru the same exact process, getting signed by the cron.\n"},{"id":"176434","messageId":"CAMOZ1BtJ5qvJt_a5vP9ddNUtZQfbWgKyh5ePNve4kqLnaEaZ4A@mail.gmail.com","threadId":"28514","inReplyTo":"7v1uv01uqm.fsf@alter.siamese.dyndns.org","subject":"Re: Lack of detached signatures","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-28T16:55:21Z","receivedAt":"2011-09-28T16:55:21Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Wed, Sep 28, 2011 at 16:45, Junio C Hamano wrote:\n\n> The world is not so blank-and-white. Trust is ultimately among humans. If\n> this message is not from the real Junio, don't you think you will hear\n> something like \"No, that c6ba05... is forgery, please don't use it!\" from\n> him, when he finds this message on the Git mailing list? If he does not\n> exercise diligence to even do that much, does he deserve your trust in the\n> first place?\n\nYou are parroting Linus's drivel.\n\nIf we get to the point where we need the real Junio yelling:\n\n DO NOT USE IT!\n\nthen things went too far long before. In that case, my trust in you as\nthe maintainer would also take a hit; I expect you to use the\navailable technology to avoid such a situation.\n\nNot everybody manages to read every [real] message of yours, so we\nneed to provide people with ways to check for themselves that the\nsources that they have *locally* already are sound.\n"},{"id":"176435","messageId":"vpqfwjg61rk.fsf@bauges.imag.fr","threadId":"28514","inReplyTo":"7v1uv01uqm.fsf@alter.siamese.dyndns.org","subject":"Re: Lack of detached signatures","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-09-28T16:59:59Z","receivedAt":"2011-09-28T16:59:59Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> The world is not so blank-and-white. Trust is ultimately among humans. If\n> this message is not from the real Junio, don't you think you will hear\n> something like \"No, that c6ba05... is forgery, please don't use it!\" from\n> him, when he finds this message on the Git mailing list? If he does not\n> exercise diligence to even do that much, does he deserve your trust in the\n> first place?\n\nThis assumes you will see the message, so while it does solve simple\nattacks like sending an email with a fake From: header to the actual\nlist, it does not solve more advanced attacks like compromising\nkernel.org's mailing-list server to avoid delivering you the forged\nemail.\n\nI know I'm being a little paranoid here, but given the recent events\nwith kernel.org, maybe we should be that paranoid :-(.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"176436","messageId":"1317228946-sup-8992@pinkfloyd.chass.utoronto.ca","threadId":"28514","inReplyTo":"4B2793BF110AAB47AB0EE7B90897038516F63A7C@ORSMSX101.amr.corp.intel.com","subject":"RE: Lack of detached signatures","fromName":"Ben Walton","fromEmail":"bwalton@artsci.utoronto.ca","sentAt":"2011-09-28T17:03:58Z","receivedAt":"2011-09-28T17:03:58Z","isPatch":false,"sender":{"key":"bdwalton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/396061?v=4"},"body":"Excerpts from Olsen, Alan R's message of Wed Sep 28 00:17:54 -0400 2011:\n\nHi Alan,\n\n> What I would like to see in git would be signed commits. I have\n> looked at what it would take to make it work, but I don't have all\n> the details worked out. (Certain merges and cherry-picks would not\n> work very well.)\n\nI'm presuming that your intent is an optional signature, not a forced\none, but for discussion, consider the monotone[1] dvcs that forces a\nsignature on every commit.\n\nWhile interesting, it was quite heavy weight. Their design was\ncomplicated by the fact that they used their own pki solution instead\nof relying on gpg (although they did integrate with gpg-agent).\nGranting access to a new user meant sharing monotone-specific keys,\netc. It's been my experience that ssh keys are challenging enough for\nmany people, and asking them to use gpg keys is just not going to fly\nunless mandated from the higher-ups.\n\nWe used monotone here for about a year and the key requirements were\nthe biggest turn off to adoption. Maybe using standard (gpg) tools\nwould have been less so, but for the most part, I don't think so.\n\nIn my (very humble) opinion, signed tags (or possibly the new signed\npush certificates) are a much better solution to this. They offer the\nsame guarantees as having every commit signed (trust of all commits\ncan be determined based on a signle signature) but leave daily\ninteractions much more light weight and flexible.\n\nThanks\n-Ben\n\n[1] http://monotone.ca\n--\nBen Walton\nSystems Programmer - CHASS\nUniversity of Toronto\nC:416.407.5610 | W:416.978.4302\n"},{"id":"176457","messageId":"20110928222542.GA18120@sigill.intra.peff.net","threadId":"28514","inReplyTo":"7v1uv01uqm.fsf@alter.siamese.dyndns.org","subject":"Re: Lack of detached signatures","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-28T22:25:43Z","receivedAt":"2011-09-28T22:25:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 28, 2011 at 09:45:21AM -0700, Junio C Hamano wrote:\n\n> The world is not so blank-and-white. Trust is ultimately among humans. If\n> this message is not from the real Junio, don't you think you will hear\n> something like \"No, that c6ba05... is forgery, please don't use it!\" from\n> him, when he finds this message on the Git mailing list? If he does not\n> exercise diligence to even do that much, does he deserve your trust in the\n> first place?\n> \n> GPG does add security (if you have the key) but you can do pretty well\n> even without it in practice.\n\nYour suggestion above is something like an audit trail. It doesn't\nprevent all mischief from happening, but after it happens and is\nnoticed, we can do some analysis, figuring out what happened and how to\nclean up. Banks do this all the time with transactions.\n\nAt the same time, banks don't rely solely on an audit trail. They also\nhave up-front mechanisms, like passwords and ATM secrets, that help\nprevent mischief from happening in the first place. And when they fail,\nwe fall back to the audit trail.\n\nSo having preventative mechanisms and audit mechanisms is not an\neither-or situation. They complement each other; the strengths of one\ncan help when the other fails.\n\nIn this case, I think signed tarballs would be a nice complement to the\nnatural human audit trail. It can stop some attacks early, without\nhaving to worry about the effort of analyzing and cleaning up after the\nfact. Can the signature be wrong, or be checked improperly? Of course.\nIf you realize your machine has been hacked and your key stolen, then\nyou let everybody know and we fall back to auditing what has already\nhappened.\n\nEach mechanism you put in place has a cost, of course. And it's worth\nthinking about whether that cost is worthwhile. But it really is as easy\nas running \"gpg --detach-sign\" when you upload a release, isn't it? You\nalready do something similar with the signed tags. So the cost of the\nmechanism is quite low.\n\n> I do not think that is true at all. Developers just dropped *.tar.gz on a\n> 'master' machine, and left the rest to a cron job that reflates the\n> tarball into *.tar.bz2, sign both using a GPG key, and mirror them to the\n> public-facing machines 'www'.\n> \n> Somebody who had access to the 'master' machine could add a new tarball\n> and have it go thru the same exact process, getting signed by the cron.\n\nRight. In theory the master machine is harder to hack than the public\nfacing mirrors, but in this case it was not. Every link in the trust\nchain introduces new possibilities for failure.\n\nGiven that git releases are all made by you, why not just sign them\nlocally with the same key you use to sign the release tags? It does mean\nyou have to generate and upload the .bz2 yourself[1], but is that really\nthat big a deal?\n\n-Peff\n\n[1] This is a minor nit, and probably not worth breaking away from the\nway the rest of the world does it, but it is somewhat silly to sign the\ncompressed data. I couldn't care less about the exact bytes in the\ncompressed version; what I care about is the actual tar file. The\ncompression is just a transport.\n"},{"id":"176461","messageId":"alpine.LNX.2.00.1109281536540.25187@bruno","threadId":"28514","inReplyTo":"7v1uv01uqm.fsf@alter.siamese.dyndns.org","subject":"Re: Lack of detached signatures","fromName":"Joseph Parmelee","fromEmail":"jparmele@wildbear.com","sentAt":"2011-09-28T22:40:33Z","receivedAt":"2011-09-28T22:40:33Z","isPatch":false,"sender":{"key":"jparmele@wildbear.com","avatar":null},"body":"\n\n\nOn Wed, 28 Sep 2011, Junio C Hamano wrote:\n\n> Joseph Parmelee writes:\n>\n>> There is confusion here between the repository and the tarball. Once you\n>> have produced the tarball there is NO cryptographic protection against\n>> forgeries unless you sign it with GPG.\n>\n> True.\n>\n> If I give you a URL http://code.google.com/p/git-core/downloads/list with\n> checksums\n>\n> $ sha1sum git-1.7.7.rc3.tar.gz\n> c6ba05a833cab49dd66dd1e252306e187effbf2b git-1.7.7.rc3.tar.gz\n>\n> You either have to trust that code.google.com/ is not broken, or this\n> message is coming from real Junio (provided if you can trust him in the\n> first place).\n>\n\nHow do I know that I am actually connected to code.google.com and not some\nother site served up to me by a bogus proxy somewhere?\n\n> BUT.\n>\n> The world is not so blank-and-white. Trust is ultimately among humans. If\n> this message is not from the real Junio, don't you think you will hear\n> something like \"No, that c6ba05... is forgery, please don't use it!\" from\n> him, when he finds this message on the Git mailing list? If he does not\n> exercise diligence to even do that much, does he deserve your trust in the\n> first place?\n>\n> GPG does add security (if you have the key) but you can do pretty well\n> even without it in practice.\n>\n\nNonsense. There is a reason why responsible sites everywhere use detached\nsignatures on their release tarballs.\n\n\n>> It is only because kernel.org exercised due diligence in the production of\n>> tags and signatures on all their tarballs that the kernel code itself\n>> withstood their recent intrusion....\n>\n> I do not think that is true at all. Developers just dropped *.tar.gz on a\n> 'master' machine, and left the rest to a cron job that reflates the\n> tarball into *.tar.bz2, sign both using a GPG key, and mirror them to the\n> public-facing machines 'www'.\n>\n> Somebody who had access to the 'master' machine could add a new tarball\n> and have it go thru the same exact process, getting signed by the cron.\n>\n\nThe \"cron job\" provided the passphrase for the signing as well instead of\nrequiring a human to authorize the transaction by providing the passphrase\nor by some other means? I suspect not. Have you actually used GPG to sign\nsomething?\n\nAnd even if that egregious error (no human authorization) had been made,\nthere is the matter of the secret signing key. Of course if the bad guys\nhave that (and the passphrase) then they have everything and can readily\nprepare fraudulent packages. But without a detached signature you are\nallowing them to do it even without going to the bother of stealing the\nsecret key and breaking/stealing the passphrase. Without a dual key\nsignature, you are providing ABSOLUTELY NO protection against\nman-in-the-middle attacks that you will never know occurred, but which will\nnevertheless (rightfully) reflect on your project. To just assert that \"you\ncan do pretty well even without it in practice\" is just plain irresponsible\nand convinces me not to update our copies of git until it returns to\nkernel.org and to administrators that understand the situation.\n"},{"id":"176464","messageId":"20110928230958.GJ19250@thunk.org","threadId":"28514","inReplyTo":"20110928222542.GA18120@sigill.intra.peff.net","subject":"Re: Lack of detached signatures","fromName":"Ted Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2011-09-28T23:09:58Z","receivedAt":"2011-09-28T23:09:58Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Sep 28, 2011 at 06:25:43PM -0400, Jeff King wrote:\n> [1] This is a minor nit, and probably not worth breaking away from the\n> way the rest of the world does it, but it is somewhat silly to sign the\n> compressed data. I couldn't care less about the exact bytes in the\n> compressed version; what I care about is the actual tar file. The\n> compression is just a transport.\n\nThe worry I have is that many users don't check the GPG checksum files\nas it is. If they have to decompress the file, and then run gpg to\ncheck the checksum, they might never get around to doing it.\n\nThat being said, I'm not sure I have a good solution. One is to ship\nthe file without using detached signatures, and ship a foo.tar.gz.gpg\nfile, and force them to use GPG to unwrap the file before it can be\nunpacked. But users would yell and scream if we did that...\n\n\t \t \t \t \t - Ted\n"},{"id":"176465","messageId":"7vd3ekxkca.fsf@alter.siamese.dyndns.org","threadId":"28514","inReplyTo":"20110928230958.GJ19250@thunk.org","subject":"Re: Lack of detached signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-29T00:28:53Z","receivedAt":"2011-09-29T00:28:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ted Ts'o writes:\n\n> On Wed, Sep 28, 2011 at 06:25:43PM -0400, Jeff King wrote:\n>> [1] This is a minor nit, and probably not worth breaking away from the\n>> way the rest of the world does it, but it is somewhat silly to sign the\n>> compressed data. I couldn't care less about the exact bytes in the\n>> compressed version; what I care about is the actual tar file. The\n>> compression is just a transport.\n>\n> The worry I have is that many users don't check the GPG checksum files\n> as it is. If they have to decompress the file, and then run gpg to\n> check the checksum, they might never get around to doing it.\n>\n> That being said, I'm not sure I have a good solution. One is to ship\n> the file without using detached signatures, and ship a foo.tar.gz.gpg\n> file, and force them to use GPG to unwrap the file before it can be\n> unpacked. But users would yell and scream if we did that...\n\nI suspect that letting GPG do the compression and shipping foo.tar.gpg\nwould work just fine as well, and it is somewhat a tempting response to a\n_demand_ to sign materials we distribute. Of course, a nicer response to a\n_request_ would be to give a detached signature ;-)\n\nI understand that the automated GPG signature k.org used to use on the\nmaster machine was primarily to protect the copies that the mirrors serve\nfrom getting tampered after they leave the master machine. Do you happen\nto know what the new policy will be? Will the developers who distribute\ntheir snapshot tarballs from the site be GPG signing them themselves\nbefore uploading? That would improve the situation (I suspect that there\nwere some people who misunderstood that these GPG signature were to\nprotect against break-in at the master machine), but at the same time, it\nmay create the chicken-and-egg bootstrapping problem if public keys of too\nmany people need to be published securely.\n"},{"id":"176468","messageId":"alpine.LNX.2.00.1109281914510.29373@bruno","threadId":"28514","inReplyTo":"20110928230958.GJ19250@thunk.org","subject":"Re: Lack of detached signatures","fromName":"Joseph Parmelee","fromEmail":"jparmele@wildbear.com","sentAt":"2011-09-29T01:29:11Z","receivedAt":"2011-09-29T01:29:11Z","isPatch":false,"sender":{"key":"jparmele@wildbear.com","avatar":null},"body":"\n\n\nOn Wed, 28 Sep 2011, Ted Ts'o wrote:\n\n> On Wed, Sep 28, 2011 at 06:25:43PM -0400, Jeff King wrote:\n>> [1] This is a minor nit, and probably not worth breaking away from the\n>> way the rest of the world does it, but it is somewhat silly to sign the\n>> compressed data. I couldn't care less about the exact bytes in the\n>> compressed version; what I care about is the actual tar file. The\n>> compression is just a transport.\n>\n> The worry I have is that many users don't check the GPG checksum files\n> as it is. If they have to decompress the file, and then run gpg to\n> check the checksum, they might never get around to doing it.\n>\n> That being said, I'm not sure I have a good solution. One is to ship\n> the file without using detached signatures, and ship a foo.tar.gz.gpg\n> file, and force them to use GPG to unwrap the file before it can be\n> unpacked. But users would yell and scream if we did that...\n>\n> \t \t \t \t \t - Ted\n>\n\n\nOr you could just provide detached signatures for the compressed tarballs\nlike they have been doing for years at kernel.org (and many other sites). \nIf tarball.tar.bz2 has a detached signature tarball.tar.bz2.sig, just\ndownload them both and:\n\n gpg --verify tarball.tar.gz.sig\n\nTo argue that some people don't avail themselves of this feature is no\nexcuse for not providing it for those of us who consider it vital. The\nbreak in at k.o is no excuse for dropping this very sensible policy which\nhas protected us for years. Just change the signing key and continue as\nbefore.\n"},{"id":"176470","messageId":"20110929014141.GA23890@sigill.intra.peff.net","threadId":"28514","inReplyTo":"20110928230958.GJ19250@thunk.org","subject":"Re: Lack of detached signatures","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-29T01:41:41Z","receivedAt":"2011-09-29T01:41:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 28, 2011 at 07:09:58PM -0400, Ted Ts'o wrote:\n\n> On Wed, Sep 28, 2011 at 06:25:43PM -0400, Jeff King wrote:\n> > [1] This is a minor nit, and probably not worth breaking away from the\n> > way the rest of the world does it, but it is somewhat silly to sign the\n> > compressed data. I couldn't care less about the exact bytes in the\n> > compressed version; what I care about is the actual tar file. The\n> > compression is just a transport.\n> \n> The worry I have is that many users don't check the GPG checksum files\n> as it is. If they have to decompress the file, and then run gpg to\n> check the checksum, they might never get around to doing it.\n\nIt shouldn't really be any more cumbersome. But at the same time, it's\ndifferent than the way everyone else does it, so any minor convenience\nwe get is probably nullified by simply confusing anybody.\n\nI wonder how many people actually check gpg checksums on downloaded\nfiles. I don't usually. But I do expect something like a package manager\nbuilding from upstream source (e.g., freebsd-style ports, or distro\npackagers pulling a new upstream) to bother to check it.\n\n> That being said, I'm not sure I have a good solution. One is to ship\n> the file without using detached signatures, and ship a foo.tar.gz.gpg\n> file, and force them to use GPG to unwrap the file before it can be\n> unpacked. But users would yell and scream if we did that...\n\nAnd rightly so. I mentioned the cost of implementing the mechanism\nbefore. If it's just \"Junio runs gpg and throws the detached signature\nup on the ftp site\", it's not a big deal. But if it's \"you can't\ndownload and install git until you have gpg installed\", that is raising\nthe bar quite a bit.\n\nIt should be the recipient's decision how much they want to trust the\ndata. We would just be helping them out by providing more information.\n\n-Peff\n"},{"id":"176471","messageId":"20110929015919.GL19250@thunk.org","threadId":"28514","inReplyTo":"7vd3ekxkca.fsf@alter.siamese.dyndns.org","subject":"Re: Lack of detached signatures","fromName":"Ted Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2011-09-29T01:59:19Z","receivedAt":"2011-09-29T01:59:19Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Sep 28, 2011 at 05:28:53PM -0700, Junio C Hamano wrote:\n> \n> I suspect that letting GPG do the compression and shipping foo.tar.gpg\n> would work just fine as well, \n\nGood point. If only \"tar -xW foo.tar.gpg\" automatically verified the\ngpg signature, that would work really well indeed. :-)\n\n> I understand that the automated GPG signature k.org used to use on the\n> master machine was primarily to protect the copies that the mirrors serve\n> from getting tampered after they leave the master machine. Do you happen\n> to know what the new policy will be? Will the developers who distribute\n> their snapshot tarballs from the site be GPG signing them themselves\n> before uploading?\n\nThis is still being negotiated. Given that developers are starting to\nsign their release tags (and of course Linus has been doing this\nalready), one of the things that I've proposed is that we support is\nto have the developer do something like this:\n\ngit archive --format=tar -o e2fsprogs-1.41.12.tar v1.41.12\ngzip -9n e2fsprogs-1.41.12.tar\ngpg --sign --detach -a e2fsprogs-1.41.12.tar.gz\n\nand then just uploading the tar.gz.gpg file, the URL for the git tree,\nand the tag that the server should use do the extraction.\n\n> That would improve the situation (I suspect that there\n> were some people who misunderstood that these GPG signature were to\n> protect against break-in at the master machine), but at the same time, it\n> may create the chicken-and-egg bootstrapping problem if public keys of too\n> many people need to be published securely.\n\nWe are in the process of bootstrapping a GPG web of trust. Linus has\ngenerated a new GPG key which has been signed by Peter Anvin, Dirk,\nand myself. We'll get a much richer set of cross signatures at the\nKernel Summit in Prague in a few months.\n\nAlso, there's a pretty good intersection between kernel developers and\nthe Debian web of trust; there's been some talk of using that as an\nauxiliary bootstrap for isolated kernel developers in distant part of\nthe world.\n\n\t\t\t\t\t- Ted\n"},{"id":"176474","messageId":"7vbou4uhuu.fsf@alter.siamese.dyndns.org","threadId":"28514","inReplyTo":"20110929015919.GL19250@thunk.org","subject":"Re: Lack of detached signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-29T03:50:49Z","receivedAt":"2011-09-29T03:50:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ted Ts'o writes:\n\n>> That would improve the situation (I suspect that there\n>> were some people who misunderstood that these GPG signature were to\n>> protect against break-in at the master machine), but at the same time, it\n>> may create the chicken-and-egg bootstrapping problem if public keys of too\n>> many people need to be published securely.\n>\n> We are in the process of bootstrapping a GPG web of trust. Linus has\n> generated a new GPG key which has been signed by Peter Anvin, Dirk,\n> and myself. We'll get a much richer set of cross signatures at the\n> Kernel Summit in Prague in a few months.\n\nI was actually more worried about helping consumers convince themselves\nthat thusly signed keys indeed belong to producers like Linus, Peter,\netc. There are those who worry that DNS record to code.google.com/ for\nthem may point at an evil place to give them rogue download material.\n\"Here are the keys you can verify our trees with\" message on the mailing\nlist, even with the message is signed with GPG, would not be satisfactory\nto them.\n"},{"id":"176484","messageId":"20110929131845.GQ19250@thunk.org","threadId":"28514","inReplyTo":"7vbou4uhuu.fsf@alter.siamese.dyndns.org","subject":"Re: Lack of detached signatures","fromName":"Ted Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2011-09-29T13:18:45Z","receivedAt":"2011-09-29T13:18:45Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Sep 28, 2011 at 08:50:49PM -0700, Junio C Hamano wrote:\n> \n> I was actually more worried about helping consumers convince themselves\n> that thusly signed keys indeed belong to producers like Linus, Peter,\n> etc. There are those who worry that DNS record to code.google.com/ for\n> them may point at an evil place to give them rogue download material.\n> \"Here are the keys you can verify our trees with\" message on the mailing\n> list, even with the message is signed with GPG, would not be satisfactory\n> to them.\n\nWhat do you mean by \"consumers\" in this context? Most end users don't\nactually download tarballs from www.kernel.org or code.google.com! :-)\n\nIf you mean developers at Linux distributions Red Hat, SuSE, or\nHandset manufacturers such as Samsung, HTC, Motorola, etc., there will\nbe many of those reprsenatives at LinuxCon Europe and CELF (Consumer\nElectronics Linux Forum) Europe conferences, which will be colocated\nwith the Kernel Summit in Prague.\n\nIf you are thinking of random developers located in far-flung places\nof the world who don't have any contact with other Linux developers,\nthis is a previously unsolved problem. There are links into the\ndeveloping Kernel GPG tree that are signed by the GPG web trust used\nby Debian, OpenSuSE, and (soon) Fedora. Given that people generally\nhave to trust one or more of those web of trusts, that's the best we\ncan do, at least as far as I know. If you can suggest something\nbetter, please let me know!\n\n\n\t\t\t\t\t\t- Ted\n"},{"id":"176488","messageId":"CAGdFq_h6shMp+d4f1bG=if6L11M_5ixN5JF7KgCrZJ44QBt0QQ@mail.gmail.com","threadId":"28514","inReplyTo":"20110929131845.GQ19250@thunk.org","subject":"Re: Lack of detached signatures","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-09-29T14:40:54Z","receivedAt":"2011-09-29T14:40:54Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Sep 29, 2011 at 15:18, Ted Ts'o wrote:\n> Handset manufacturers such as Samsung, HTC, Motorola, etc., there will\n> be many of those reprsenatives at LinuxCon Europe and CELF (Consumer\n> Electronics Linux Forum) Europe conferences, which will be colocated\n> with the Kernel Summit in Prague.\n>\n> If you are thinking of random developers located in far-flung places\n> of the world who don't have any contact with other Linux developers,\n> this is a previously unsolved problem.  There are links into the\n> developing Kernel GPG tree that are signed by the GPG web trust used\n> by Debian, OpenSuSE, and (soon) Fedora.  Given that people generally\n> have to trust one or more of those web of trusts, that's the best we\n> can do, at least as far as I know.  If you can suggest something\n> better, please let me know!\n\nThis all sounds very interesting. Where is this discussion on a new\nweb of trust taking place? The kernel mailing list? Do you have a\nmessage-id / gmane.org link for me to read more about this perhaps?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"176490","messageId":"20110929145046.GC13705@thunk.org","threadId":"28514","inReplyTo":"CAGdFq_h6shMp+d4f1bG=if6L11M_5ixN5JF7KgCrZJ44QBt0QQ@mail.gmail.com","subject":"Re: Lack of detached signatures","fromName":"Ted Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2011-09-29T14:50:46Z","receivedAt":"2011-09-29T14:50:46Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Sep 29, 2011 at 04:40:54PM +0200, Sverre Rabbelier wrote:\n> \n> This all sounds very interesting. Where is this discussion on a new\n> web of trust taking place? The kernel mailing list? Do you have a\n> message-id / gmane.org link for me to read more about this perhaps?\n\nIt's been taking place on private e-mails and on conference calls\namongst those of us who have been organizing the kernel.org recovery\nefforts. There will be a more detailed discussion and a GPG key\nsigning party that I will be organizing at the upcoming kernel summit\nmeeting in Prague.\n\nWhat are your concerns?\n\n\t\t\t\t\t- Ted\n"},{"id":"176491","messageId":"CAGdFq_gCkGkSnoHHdOpRb1+RP6YXPSEOwYVTbCZHeHtHzsaB9g@mail.gmail.com","threadId":"28514","inReplyTo":"20110929145046.GC13705@thunk.org","subject":"Re: Lack of detached signatures","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-09-29T14:52:51Z","receivedAt":"2011-09-29T14:52:51Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Sep 29, 2011 at 16:50, Ted Ts'o wrote:\n> On Thu, Sep 29, 2011 at 04:40:54PM +0200, Sverre Rabbelier wrote:\n>>\n>> This all sounds very interesting. Where is this discussion on a new\n>> web of trust taking place? The kernel mailing list? Do you have a\n>> message-id / gmane.org link for me to read more about this perhaps?\n>\n> It's been taking place on private e-mails and on conference calls\n> amongst those of us who have been organizing the kernel.org recovery\n> efforts.  There will be a more detailed discussion and a GPG key\n> signing party that I will be organizing at the upcoming kernel summit\n> meeting in Prague.\n>\n> What are your concerns?\n\nNot concerned at all. I just would have enjoyed listening in to those\nmore knowledgeable than me discussing security and trust :).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"176500","messageId":"alpine.LNX.2.00.1109291013220.29373@bruno","threadId":"28514","inReplyTo":"20110929131845.GQ19250@thunk.org","subject":"Re: Lack of detached signatures","fromName":"Joseph Parmelee","fromEmail":"jparmele@wildbear.com","sentAt":"2011-09-29T16:47:30Z","receivedAt":"2011-09-29T16:47:30Z","isPatch":false,"sender":{"key":"jparmele@wildbear.com","avatar":null},"body":"\n\n\nOn Thu, 29 Sep 2011, Ted Ts'o wrote:\n\n> On Wed, Sep 28, 2011 at 08:50:49PM -0700, Junio C Hamano wrote:\n>>\n>> I was actually more worried about helping consumers convince themselves\n>> that thusly signed keys indeed belong to producers like Linus, Peter,\n>> etc. There are those who worry that DNS record to code.google.com/ for\n>> them may point at an evil place to give them rogue download material.\n>> \"Here are the keys you can verify our trees with\" message on the mailing\n>> list, even with the message is signed with GPG, would not be satisfactory\n>> to them.\n>\n> What do you mean by \"consumers\" in this context? Most end users don't\n> actually download tarballs from www.kernel.org or code.google.com! :-)\n>\n> If you mean developers at Linux distributions Red Hat, SuSE, or\n> Handset manufacturers such as Samsung, HTC, Motorola, etc., there will\n> be many of those reprsenatives at LinuxCon Europe and CELF (Consumer\n> Electronics Linux Forum) Europe conferences, which will be colocated\n> with the Kernel Summit in Prague.\n>\n> If you are thinking of random developers located in far-flung places\n> of the world who don't have any contact with other Linux developers,\n> this is a previously unsolved problem. There are links into the\n> developing Kernel GPG tree that are signed by the GPG web trust used\n> by Debian, OpenSuSE, and (soon) Fedora. Given that people generally\n> have to trust one or more of those web of trusts, that's the best we\n> can do, at least as far as I know. If you can suggest something\n> better, please let me know!\n>\n>\n> \t\t\t\t\t\t- Ted\n>\n\nAlso included is distro developers that gen custom distros for limited\ncorporate use on specific hardware, and anyone else that is sufficiently\nconcerned about security and/or survivability that they prefer/need to build\nfrom the upstream source.\n\nAs far as accepting public keys, a key obtained from the key servers and\nsigned by others, while not perfect, is vastly superior to nothing at all. \nI am located in the mountains of Costa Rica. Over the years I have\ncollected a fair number of public keys making it very difficult for bad guys\nto fake both a public key and all the signatures too, even though I can't\ntravel to a \"key signing party\" which would of course be better.\n\nEven if we have to change all the keys now its going to be risky but still\nvastly better than nothing. I would hope that a new key would be signed by\nan existing valid private key as well as newly issued keys. This would\nreassure people like me who have a substantial stash of old but valid public\nkeys, while at the same time thwarting bad guys who can fake only those old\nsignatures for which they have stolen valid private keys.\n\nJoseph\n"},{"id":"176520","messageId":"4B2793BF110AAB47AB0EE7B90897038516F68647@ORSMSX101.amr.corp.intel.com","threadId":"28514","inReplyTo":"20110928230958.GJ19250@thunk.org","subject":"RE: Lack of detached signatures","fromName":"Olsen, Alan R","fromEmail":"alan.r.olsen@intel.com","sentAt":"2011-09-29T20:31:02Z","receivedAt":"2011-09-29T20:31:02Z","isPatch":false,"sender":{"key":"alan.r.olsen@intel.com","avatar":null},"body":"[Sorry for the top posting. Fscking Outlook demands it.]\n\nThe 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.\n\nWhat 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.)\n\n-----Original Message-----\nFrom: Ted Ts'o [mailto:tytso@mit.edu] \nSent: Wednesday, September 28, 2011 4:10 PM\nTo: Jeff King\nCc: Junio C Hamano; Joseph Parmelee; Carlos Martín Nieto; Olsen, Alan R; Michael Witten; git@vger.kernel.org\nSubject: Re: Lack of detached signatures\n\nOn Wed, Sep 28, 2011 at 06:25:43PM -0400, Jeff King wrote:\n> [1] This is a minor nit, and probably not worth breaking away from the\n> way the rest of the world does it, but it is somewhat silly to sign the\n> compressed data. I couldn't care less about the exact bytes in the\n> compressed version; what I care about is the actual tar file. The\n> compression is just a transport.\n\nThe worry I have is that many users don't check the GPG checksum files\nas it is. If they have to decompress the file, and then run gpg to\ncheck the checksum, they might never get around to doing it.\n\nThat being said, I'm not sure I have a good solution. One is to ship\nthe file without using detached signatures, and ship a foo.tar.gz.gpg\nfile, and force them to use GPG to unwrap the file before it can be\nunpacked. But users would yell and scream if we did that...\n\n\t \t \t \t \t - Ted\n"}]}