{"thread":{"id":"47569","subject":"upstreaming https://github.com/cgwalters/git-evtag ?","startedAt":"2018-01-08T20:12:06Z","lastAt":"2018-01-10T16:36:27Z","messageCount":11,"participants":["Colin Walters","Johannes Schindelin","Santiago Torres","Stefan Beller","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"336184","messageId":"1515442320.3241451.1228399576.66D7DA96@webmail.messagingengine.com","threadId":"47569","inReplyTo":null,"subject":"upstreaming https://github.com/cgwalters/git-evtag ?","fromName":"Colin Walters","fromEmail":"walters@verbum.org","sentAt":"2018-01-08T20:12:00Z","receivedAt":"2018-01-08T20:12:06Z","isPatch":false,"sender":{"key":"walters@verbum.org","avatar":"https://gravatar.com/avatar/793625733050359d5917f5375179e5af7d2a56dca197661f6f709c4ad69cd7f2?d=mp&s=160"},"body":"Hi, so quite a while ago I wrote this:\nhttps://github.com/cgwalters/git-evtag\n\nSince I last posted about this on the list here, of course\nshattered.io happened. It also looks\nlike there was a node.js implementation written.\n\nAny interest in having this in core git? \n"},{"id":"336189","messageId":"nycvar.QRO.7.76.6.1801082132510.31@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"47569","inReplyTo":"1515442320.3241451.1228399576.66D7DA96@webmail.messagingengine.com","subject":"Re: upstreaming https://github.com/cgwalters/git-evtag ?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-01-08T20:34:45Z","receivedAt":"2018-01-08T20:34:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 8 Jan 2018, Colin Walters wrote:\n\n> Hi, so quite a while ago I wrote this:\n> https://github.com/cgwalters/git-evtag\n\nFor the benefit of readers who prefer to stay in their mail readers:\n\n\tgit-evtag\n\n\tgit-evtag can be used as a replacement for git-tag -s. It will\n\tgenerate a strong checksum (called Git-EVTag-v0-SHA512) over the\n\tcommit, tree, and blobs it references (and recursively over\n\tsubmodules). A primary rationale for this is that the underlying SHA1\n\talgorithm of git is under increasing threat. Further, a goal here\n\tis to create a checksum that covers the entire source of a single\n\trevision as a replacement for tarballs + checksums.\n\n> Since I last posted about this on the list here, of course\n> shattered.io happened. It also looks\n> like there was a node.js implementation written.\n> \n> Any interest in having this in core git? \n\nI have no opinion, I was just curious what this otherwise undescribed\nthing was about.\n\nCiao,\nJohannes\n"},{"id":"336193","messageId":"20180108204029.m42qyezojak4kohh@LykOS.localdomain","threadId":"47569","inReplyTo":"1515442320.3241451.1228399576.66D7DA96@webmail.messagingengine.com","subject":"Re: upstreaming https://github.com/cgwalters/git-evtag ?","fromName":"Santiago Torres","fromEmail":"santiago@nyu.edu","sentAt":"2018-01-08T20:40:30Z","receivedAt":"2018-01-08T20:38:00Z","isPatch":false,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"Hi,\n\nI personally like the idea of git-evtags, but I feel that they could be\nmade so that push certificates (and being hash-algorithm agnostic)\nshould provide the same functionality with less code.\n\nTo me, a git evtag is basically a signed tag + a data structure similar\nto a push certificate embedded in it. I wonder if, with the current\ntooling in git, this could be done as a custom command...\n\nCheers!\n-Santiago.\n\nOn Mon, Jan 08, 2018 at 03:12:00PM -0500, Colin Walters wrote:\n> Hi, so quite a while ago I wrote this:\n> https://github.com/cgwalters/git-evtag\n> \n> Since I last posted about this on the list here, of course\n> shattered.io happened. It also looks\n> like there was a node.js implementation written.\n> \n> Any interest in having this in core git? \n"},{"id":"336194","messageId":"1515444153.3249266.1228432904.51A92479@webmail.messagingengine.com","threadId":"47569","inReplyTo":"20180108204029.m42qyezojak4kohh@LykOS.localdomain","subject":"Re: upstreaming https://github.com/cgwalters/git-evtag ?","fromName":"Colin Walters","fromEmail":"walters@verbum.org","sentAt":"2018-01-08T20:42:33Z","receivedAt":"2018-01-08T20:42:37Z","isPatch":false,"sender":{"key":"walters@verbum.org","avatar":"https://gravatar.com/avatar/793625733050359d5917f5375179e5af7d2a56dca197661f6f709c4ad69cd7f2?d=mp&s=160"},"body":"\n\nOn Mon, Jan 8, 2018, at 3:40 PM, Santiago Torres wrote:\n> Hi,\n> \n> I personally like the idea of git-evtags, but I feel that they could be\n> made so that push certificates (and being hash-algorithm agnostic)\n> should provide the same functionality with less code.\n\nWhat's a \"push certificate\"? (I really tried to find it in Google,\neven going to page 4 where one can start to see tumbleweeds\ngoing by... I'm fairly certain you're not talking about something related\nto iOS notifications) \n"},{"id":"336196","messageId":"CAGZ79kZ8AXezcX1_5WJsUJMHiHCzj2B=Uj8+4K3VF+cC6mTCqA@mail.gmail.com","threadId":"47569","inReplyTo":"20180108204029.m42qyezojak4kohh@LykOS.localdomain","subject":"Re: upstreaming https://github.com/cgwalters/git-evtag ?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-01-08T20:49:01Z","receivedAt":"2018-01-08T20:49:09Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Jan 8, 2018 at 12:40 PM, Santiago Torres wrote:\n> Hi,\n>\n> I personally like the idea of git-evtags, but I feel that they could be\n> made so that push certificates (and being hash-algorithm agnostic)\n> should provide the same functionality with less code.\n>\n> To me, a git evtag is basically a signed tag + a data structure similar\n> to a push certificate embedded in it. I wonder if, with the current\n> tooling in git, this could be done as a custom command...\n\nIn that case, why not migrate Git to a new hash function instead\nof adding a very niche fixup?\n\nSee Documentation/technical/hash-function-transition.txt\nfor how to do it.\n\nPersonally I'd dislike to include ev-tags as it might send a signal\nof \"papering over sha1 issues instead of fixing it\".\n\npush certificates are somewhat underdocumented, see the\ngit-push man page, which contains\n --[no-]signed, --signed=(true|false|if-asked)\n GPG-sign the push request to update refs on the\n receiving side, to allow it to be checked by the\n hooks and/or be logged. If false or --no-signed, no\n signing will be attempted. If true or --signed, the\n push will fail if the server does not support signed\n pushes. If set to if-asked, sign if and only if the\n server supports signed pushes. The push will also\n fail if the actual call to gpg --sign fails. See git-\n receive-pack(1) for the details on the receiving end.\n\nGoing to receive-pack(1), there is an excerpt:\n\n When accepting a signed push (see git-push(1)), the\n signed push certificate is stored in a blob and an\n environment variable GIT_PUSH_CERT can be consulted for\n its object name. See the description of post-receive hook\n for an example. In addition, the certificate is verified\n using GPG and the result is exported with the following\n environment variables:\n...\n\n\nStefan\n"},{"id":"336197","messageId":"20180108205138.jak7ahdppotgcckz@LykOS.localdomain","threadId":"47569","inReplyTo":"1515444153.3249266.1228432904.51A92479@webmail.messagingengine.com","subject":"Re: upstreaming https://github.com/cgwalters/git-evtag ?","fromName":"Santiago Torres","fromEmail":"santiago@nyu.edu","sentAt":"2018-01-08T20:51:39Z","receivedAt":"2018-01-08T20:49:11Z","isPatch":false,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"Yeah, I see where you're coming from. I don't think push certificates\nhave caught on yet...\n\nYou can read on them on [1], and also under the\nDocumentation/git-push:147.\n\nThere's also another PR trying to make a sample hook for signed\npushes on [2].\n\nThe basic idea is to push a signed data structure with relevant git\nreference information as a git object to avoid a server/mitm from moving\nreferences around.\n\nCheers!\n-Santiago.\n\n[1] https://public-inbox.org/git/1408485987-3590-1-git-send-email-gitster@pobox.com/\n[2] https://public-inbox.org/git/20171202091248.6037-1-root@shikherverma.com/\n\nOn Mon, Jan 08, 2018 at 03:42:33PM -0500, Colin Walters wrote:\n> \n> \n> On Mon, Jan 8, 2018, at 3:40 PM, Santiago Torres wrote:\n> > Hi,\n> > \n> > I personally like the idea of git-evtags, but I feel that they could be\n> > made so that push certificates (and being hash-algorithm agnostic)\n> > should provide the same functionality with less code.\n> \n> What's a \"push certificate\"? (I really tried to find it in Google,\n> even going to page 4 where one can start to see tumbleweeds\n> going by... I'm fairly certain you're not talking about something related\n> to iOS notifications) \n"},{"id":"336198","messageId":"20180108205454.6ky352nkdn5u4w22@LykOS.localdomain","threadId":"47569","inReplyTo":"CAGZ79kZ8AXezcX1_5WJsUJMHiHCzj2B=Uj8+4K3VF+cC6mTCqA@mail.gmail.com","subject":"Re: upstreaming https://github.com/cgwalters/git-evtag ?","fromName":"Santiago Torres","fromEmail":"santiago@nyu.edu","sentAt":"2018-01-08T20:54:54Z","receivedAt":"2018-01-08T20:52:24Z","isPatch":false,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"> Personally I'd dislike to include ev-tags as it might send a signal\n> of \"papering over sha1 issues instead of fixing it\".\n\n+1. I probably didn't convey it well, but this is what I was hoping for.\nI think git has enough building blocks to provide something akin to git\nevtags already.\n\nThanks,\n-Santiago.\n"},{"id":"336219","messageId":"1515465051.2895186.1228754952.0036D645@webmail.messagingengine.com","threadId":"47569","inReplyTo":"CAGZ79kZ8AXezcX1_5WJsUJMHiHCzj2B=Uj8+4K3VF+cC6mTCqA@mail.gmail.com","subject":"Re: upstreaming https://github.com/cgwalters/git-evtag ?","fromName":"Colin Walters","fromEmail":"walters@verbum.org","sentAt":"2018-01-09T02:30:51Z","receivedAt":"2018-01-09T02:31:02Z","isPatch":false,"sender":{"key":"walters@verbum.org","avatar":"https://gravatar.com/avatar/793625733050359d5917f5375179e5af7d2a56dca197661f6f709c4ad69cd7f2?d=mp&s=160"},"body":"\n\nOn Mon, Jan 8, 2018, at 3:49 PM, Stefan Beller wrote:\n> On Mon, Jan 8, 2018 at 12:40 PM, Santiago Torres wrote:\n> > Hi,\n> >\n> > I personally like the idea of git-evtags, but I feel that they could be\n> > made so that push certificates (and being hash-algorithm agnostic)\n> > should provide the same functionality with less code.\n> >\n> > To me, a git evtag is basically a signed tag + a data structure similar\n> > to a push certificate embedded in it. I wonder if, with the current\n> > tooling in git, this could be done as a custom command...\n> \n> In that case, why not migrate Git to a new hash function instead\n> of adding a very niche fixup?\n\nEvery day, for many years I find it maddening and really ridiculous\nthat the Fedora package build process insists I provide it a tarball\ninstead of being able to just fetch a signed git tag.\n\nNow while I haven't fought the battle to teach Fedora to actually use\nthis, I think I have a pretty strong argument that git-evtag very clearly\nfulfills the same role that a signed tarball does.\n\nIn particular, how a single checksum covers the entire source - no\nhash tree involved. The way that the evtag is \"horizontal\" across\nthe source while the git tree is \"vertical\" around history means\nthey're complementary.\n \n> See Documentation/technical/hash-function-transition.txt\n> for how to do it.\n\nevtag took me a day or two to write initially and doesn't\nimpose any requirements on users except a small additional\nbit of software.\n\nIn contrast, working on hash-function-transition.txt? That\nseems like it'd easily consume many person-months of work.\nAnd that plan only exists post-shatter.io, whereas git-evtag\nlong predates both.\n\n> Personally I'd dislike to include ev-tags as it might send a signal\n> of \"papering over sha1 issues instead of fixing it\".\n\nI don't agree. I think it's pretty clear that a hash function transition\nwould be a huge amount of work - not least because of course\nthere are now at least two widely used implementations of git in C,\nplus https://www.eclipse.org/jgit/ plus...\n\n> push certificates are somewhat underdocumented, see the\n\nWhy not call them \"git signed pushes\"? Junio's post\neven says \"the signed push\".\n\nAnd I just looked at this a little bit more but I'm not sure I\nsee how this covers the same goal as evtags; it seems\nmore about stopping someone from MITM my push\nto github.com, and not about ensuring integrity from\nsomeone pulling from github.com (and not wanting\nto fully trust github).\n"},{"id":"336274","messageId":"20180109180933.jbyidmmv5xpsjuae@LykOS.localdomain","threadId":"47569","inReplyTo":"1515465051.2895186.1228754952.0036D645@webmail.messagingengine.com","subject":"Re: upstreaming https://github.com/cgwalters/git-evtag ?","fromName":"Santiago Torres","fromEmail":"santiago@nyu.edu","sentAt":"2018-01-09T18:09:34Z","receivedAt":"2018-01-09T18:07:04Z","isPatch":false,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"> > See Documentation/technical/hash-function-transition.txt\n> > for how to do it.\n> \n> evtag took me a day or two to write initially and doesn't\n> impose any requirements on users except a small additional\n> bit of software.\n\nI agree that, in nature it shouldn't be difficult, but I also think that\nthings usually take longer when you try to minimize code reuse and\nstreamline the system's design.\n\n> In contrast, working on hash-function-transition.txt? That\n> seems like it'd easily consume many person-months of work.\n> And that plan only exists post-shatter.io, whereas git-evtag\n> long predates both.\n\nI think this is partly true. A hash transition has been brought up\nmultiple times pre-shattered. In my opinion shattered was a much-needed\nPR push for SHA1 deprecation. In practice, things changed very little.\n\n> > Personally I'd dislike to include ev-tags as it might send a signal\n> > of \"papering over sha1 issues instead of fixing it\".\n> \n> I don't agree. I think it's pretty clear that a hash function transition\n> would be a huge amount of work - not least because of course\n> there are now at least two widely used implementations of git in C,\n> plus https://www.eclipse.org/jgit/ plus...\n\nI agree with Stefan here. I think it's better in the long-term to\npush for hash-agnosticity. I don't know if git-evtag is hash agnostic,\nbut if it is not, then we have two transition plans to think about.\n\n> \n> > push certificates are somewhat underdocumented, see the\n> \n> Why not call them \"git signed pushes\"? Junio's post\n> even says \"the signed push\".\n\nA signed push creates a push certificate.\n> \n> And I just looked at this a little bit more but I'm not sure I\n> see how this covers the same goal as evtags;\n\nCorrect me if I'm wrong (it's been a couple of years) but last time I\nread about git evtags, they basically did the following:\n\n 1. Create a signed tag.\n 2. Create a signed statement of all the references.\n 3. Create a checksum of the checked out code on the tag.\n 4. Create a tarball of it.\n\nI think 1) is already happening, 2) is very similar information to the\none contained in a push certificate. I don't know how necessary are 3)\nand 4), but that's just my very opinionated take on it.\n\nFull disclosure, I published a \"competing\" solution a couple of years\nago[1] but, in my personal opinion, I think push certificates can\nachieve the same security guarantees as my system with very little\nchanges.\n\nCheers!\n-Santiago.\n\n[1] https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias\n"},{"id":"336314","messageId":"20180109203849.GA30468@aiede.svl.corp.google.com","threadId":"47569","inReplyTo":"20180109180933.jbyidmmv5xpsjuae@LykOS.localdomain","subject":"Re: upstreaming https://github.com/cgwalters/git-evtag ?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-01-09T20:38:49Z","receivedAt":"2018-01-09T20:39:39Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nSantiago Torres wrote:\n\n>> In contrast, working on hash-function-transition.txt? That\n>> seems like it'd easily consume many person-months of work.\n>> And that plan only exists post-shatter.io, whereas git-evtag\n>> long predates both.\n>\n> I think this is partly true. A hash transition has been brought up\n> multiple times pre-shattered. In my opinion shattered was a much-needed\n> PR push for SHA1 deprecation. In practice, things changed very little.\n\nSure, the main relevant things that changed are:\n\n 1. The sha1collisiondetection library became well known, which if\n anything makes moving off of SHA-1 *less* urgent than before (but\n still urgent).\n\nand\n\n 2. We came up with and agreed on a design for a transition off of\n SHA-1 that we are (slowly but surely) executing on. This means\n it's a good time to help get it done.\n\n>>> Personally I'd dislike to include ev-tags as it might send a signal\n>>> of \"papering over sha1 issues instead of fixing it\".\n>>\n>> I don't agree. I think it's pretty clear that a hash function transition\n>> would be a huge amount of work - not least because of course\n>> there are now at least two widely used implementations of git in C,\n>> plus https://www.eclipse.org/jgit/ plus...\n>\n> I agree with Stefan here. I think it's better in the long-term to\n> push for hash-agnosticity. I don't know if git-evtag is hash agnostic,\n> but if it is not, then we have two transition plans to think about.\n\nI don't think there's even a question here: Git has to transition off\nof SHA-1.\n\nIn that context, Stefan's comment is a welcome one: once we've\ntransitioned off of SHA-1, having a separate evtag feature would make\ngit more complicated without any benefit to match. To put it another\nway, the gpgsig-sha256 field described in\nDocumentation/technical/hash-function-transition.txt provides\nessentially the same functionality as an evtag. What's missing is an\nimplementation of it.\n\nI'm happy to help in any way I can (reviews, advice, etc).\n\n[...]\n> Full disclosure, I published a \"competing\" solution a couple of years\n> ago[1] but, in my personal opinion, I think push certificates can\n> achieve the same security guarantees as my system with very little\n> changes.\n\nWork to improve the usability of push certs would also be very very\nwelcome.\n\nThanks and hope that helps,\nJonathan\n\n> [1] https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias\n"},{"id":"336393","messageId":"20180110163856.5uy4lbon322ey3ns@LykOS.localdomain","threadId":"47569","inReplyTo":"20180109203849.GA30468@aiede.svl.corp.google.com","subject":"Re: upstreaming https://github.com/cgwalters/git-evtag ?","fromName":"Santiago Torres","fromEmail":"santiago@nyu.edu","sentAt":"2018-01-10T16:38:57Z","receivedAt":"2018-01-10T16:36:27Z","isPatch":false,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"> > push for hash-agnosticity. I don't know if git-evtag is hash agnostic,\n> > but if it is not, then we have two transition plans to think about.\n> \n> I don't think there's even a question here: Git has to transition off\n> of SHA-1.\n> \n> In that context, Stefan's comment is a welcome one: once we've\n> transitioned off of SHA-1, having a separate evtag feature would make\n> git more complicated without any benefit to match. To put it another\n> way, the gpgsig-sha256 field described in\n> Documentation/technical/hash-function-transition.txt provides\n> essentially the same functionality as an evtag. What's missing is an\n> implementation of it.\n> \n> I'm happy to help in any way I can (reviews, advice, etc).\n\nSame here, although I'm a bit swamped with other work... \n\n> \n> > Full disclosure, I published a \"competing\" solution a couple of years\n> > ago[1] but, in my personal opinion, I think push certificates can\n> > achieve the same security guarantees as my system with very little\n> > changes.\n> \n> Work to improve the usability of push certs would also be very very\n> welcome.\n\nI agree. I personally think that at least the sample hook work on here\nwould be a good candidate for this[1], although I don't know what's the\nstatus of it. The way they are right now, they should at least warn when\npush certificates are not enabled on the server side (i.e., there is no\nhook to handle it).\n\n> \n> Thanks and hope that helps,\n> Jonathan\n\nNo, thanks to you :)\n\n-Santiago.\n\n[1] https://public-inbox.org/git/20171202091248.6037-1-root@shikherverma.com/\n"}]}