* upstreaming https://github.com/cgwalters/git-evtag ? @ 2018-01-08 20:12 Colin Walters 2018-01-08 20:34 ` Johannes Schindelin 2018-01-08 20:40 ` Santiago Torres 0 siblings, 2 replies; 11+ messages in thread From: Colin Walters @ 2018-01-08 20:12 UTC (permalink / raw) To: git Hi, so quite a while ago I wrote this: https://github.com/cgwalters/git-evtag Since I last posted about this on the list here, of course shattered.io happened. It also looks like there was a node.js implementation written. Any interest in having this in core git? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: upstreaming https://github.com/cgwalters/git-evtag ? 2018-01-08 20:12 upstreaming https://github.com/cgwalters/git-evtag ? Colin Walters @ 2018-01-08 20:34 ` Johannes Schindelin 2018-01-08 20:40 ` Santiago Torres 1 sibling, 0 replies; 11+ messages in thread From: Johannes Schindelin @ 2018-01-08 20:34 UTC (permalink / raw) To: Colin Walters; +Cc: git Hi, On Mon, 8 Jan 2018, Colin Walters wrote: > Hi, so quite a while ago I wrote this: > https://github.com/cgwalters/git-evtag For the benefit of readers who prefer to stay in their mail readers: git-evtag git-evtag can be used as a replacement for git-tag -s. It will generate a strong checksum (called Git-EVTag-v0-SHA512) over the commit, tree, and blobs it references (and recursively over submodules). A primary rationale for this is that the underlying SHA1 algorithm of git is under increasing threat. Further, a goal here is to create a checksum that covers the entire source of a single revision as a replacement for tarballs + checksums. > Since I last posted about this on the list here, of course > shattered.io happened. It also looks > like there was a node.js implementation written. > > Any interest in having this in core git? I have no opinion, I was just curious what this otherwise undescribed thing was about. Ciao, Johannes ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: upstreaming https://github.com/cgwalters/git-evtag ? 2018-01-08 20:12 upstreaming https://github.com/cgwalters/git-evtag ? Colin Walters 2018-01-08 20:34 ` Johannes Schindelin @ 2018-01-08 20:40 ` Santiago Torres 2018-01-08 20:42 ` Colin Walters 2018-01-08 20:49 ` Stefan Beller 1 sibling, 2 replies; 11+ messages in thread From: Santiago Torres @ 2018-01-08 20:40 UTC (permalink / raw) To: Colin Walters; +Cc: git [-- Attachment #1: Type: text/plain, Size: 788 bytes --] Hi, I personally like the idea of git-evtags, but I feel that they could be made so that push certificates (and being hash-algorithm agnostic) should provide the same functionality with less code. To me, a git evtag is basically a signed tag + a data structure similar to a push certificate embedded in it. I wonder if, with the current tooling in git, this could be done as a custom command... Cheers! -Santiago. On Mon, Jan 08, 2018 at 03:12:00PM -0500, Colin Walters wrote: > Hi, so quite a while ago I wrote this: > https://github.com/cgwalters/git-evtag > > Since I last posted about this on the list here, of course > shattered.io happened. It also looks > like there was a node.js implementation written. > > Any interest in having this in core git? [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: upstreaming https://github.com/cgwalters/git-evtag ? 2018-01-08 20:40 ` Santiago Torres @ 2018-01-08 20:42 ` Colin Walters 2018-01-08 20:51 ` Santiago Torres 2018-01-08 20:49 ` Stefan Beller 1 sibling, 1 reply; 11+ messages in thread From: Colin Walters @ 2018-01-08 20:42 UTC (permalink / raw) To: Santiago Torres; +Cc: git On Mon, Jan 8, 2018, at 3:40 PM, Santiago Torres wrote: > Hi, > > I personally like the idea of git-evtags, but I feel that they could be > made so that push certificates (and being hash-algorithm agnostic) > should provide the same functionality with less code. What's a "push certificate"? (I really tried to find it in Google, even going to page 4 where one can start to see tumbleweeds going by... I'm fairly certain you're not talking about something related to iOS notifications) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: upstreaming https://github.com/cgwalters/git-evtag ? 2018-01-08 20:42 ` Colin Walters @ 2018-01-08 20:51 ` Santiago Torres 0 siblings, 0 replies; 11+ messages in thread From: Santiago Torres @ 2018-01-08 20:51 UTC (permalink / raw) To: Colin Walters; +Cc: git [-- Attachment #1: Type: text/plain, Size: 1209 bytes --] Yeah, I see where you're coming from. I don't think push certificates have caught on yet... You can read on them on [1], and also under the Documentation/git-push:147. There's also another PR trying to make a sample hook for signed pushes on [2]. The basic idea is to push a signed data structure with relevant git reference information as a git object to avoid a server/mitm from moving references around. Cheers! -Santiago. [1] https://public-inbox.org/git/1408485987-3590-1-git-send-email-gitster@pobox.com/ [2] https://public-inbox.org/git/20171202091248.6037-1-root@shikherverma.com/ On Mon, Jan 08, 2018 at 03:42:33PM -0500, Colin Walters wrote: > > > On Mon, Jan 8, 2018, at 3:40 PM, Santiago Torres wrote: > > Hi, > > > > I personally like the idea of git-evtags, but I feel that they could be > > made so that push certificates (and being hash-algorithm agnostic) > > should provide the same functionality with less code. > > What's a "push certificate"? (I really tried to find it in Google, > even going to page 4 where one can start to see tumbleweeds > going by... I'm fairly certain you're not talking about something related > to iOS notifications) [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: upstreaming https://github.com/cgwalters/git-evtag ? 2018-01-08 20:40 ` Santiago Torres 2018-01-08 20:42 ` Colin Walters @ 2018-01-08 20:49 ` Stefan Beller 2018-01-08 20:54 ` Santiago Torres 2018-01-09 2:30 ` Colin Walters 1 sibling, 2 replies; 11+ messages in thread From: Stefan Beller @ 2018-01-08 20:49 UTC (permalink / raw) To: Santiago Torres; +Cc: Colin Walters, git On Mon, Jan 8, 2018 at 12:40 PM, Santiago Torres <santiago@nyu.edu> wrote: > Hi, > > I personally like the idea of git-evtags, but I feel that they could be > made so that push certificates (and being hash-algorithm agnostic) > should provide the same functionality with less code. > > To me, a git evtag is basically a signed tag + a data structure similar > to a push certificate embedded in it. I wonder if, with the current > tooling in git, this could be done as a custom command... In that case, why not migrate Git to a new hash function instead of adding a very niche fixup? See Documentation/technical/hash-function-transition.txt for how to do it. Personally I'd dislike to include ev-tags as it might send a signal of "papering over sha1 issues instead of fixing it". push certificates are somewhat underdocumented, see the git-push man page, which contains --[no-]signed, --signed=(true|false|if-asked) GPG-sign the push request to update refs on the receiving side, to allow it to be checked by the hooks and/or be logged. If false or --no-signed, no signing will be attempted. If true or --signed, the push will fail if the server does not support signed pushes. If set to if-asked, sign if and only if the server supports signed pushes. The push will also fail if the actual call to gpg --sign fails. See git- receive-pack(1) for the details on the receiving end. Going to receive-pack(1), there is an excerpt: When accepting a signed push (see git-push(1)), the signed push certificate is stored in a blob and an environment variable GIT_PUSH_CERT can be consulted for its object name. See the description of post-receive hook for an example. In addition, the certificate is verified using GPG and the result is exported with the following environment variables: ... Stefan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: upstreaming https://github.com/cgwalters/git-evtag ? 2018-01-08 20:49 ` Stefan Beller @ 2018-01-08 20:54 ` Santiago Torres 2018-01-09 2:30 ` Colin Walters 1 sibling, 0 replies; 11+ messages in thread From: Santiago Torres @ 2018-01-08 20:54 UTC (permalink / raw) To: Stefan Beller; +Cc: Colin Walters, git [-- Attachment #1: Type: text/plain, Size: 307 bytes --] > Personally I'd dislike to include ev-tags as it might send a signal > of "papering over sha1 issues instead of fixing it". +1. I probably didn't convey it well, but this is what I was hoping for. I think git has enough building blocks to provide something akin to git evtags already. Thanks, -Santiago. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: upstreaming https://github.com/cgwalters/git-evtag ? 2018-01-08 20:49 ` Stefan Beller 2018-01-08 20:54 ` Santiago Torres @ 2018-01-09 2:30 ` Colin Walters 2018-01-09 18:09 ` Santiago Torres 1 sibling, 1 reply; 11+ messages in thread From: Colin Walters @ 2018-01-09 2:30 UTC (permalink / raw) To: Stefan Beller, Santiago Torres; +Cc: git On Mon, Jan 8, 2018, at 3:49 PM, Stefan Beller wrote: > On Mon, Jan 8, 2018 at 12:40 PM, Santiago Torres <santiago@nyu.edu> wrote: > > Hi, > > > > I personally like the idea of git-evtags, but I feel that they could be > > made so that push certificates (and being hash-algorithm agnostic) > > should provide the same functionality with less code. > > > > To me, a git evtag is basically a signed tag + a data structure similar > > to a push certificate embedded in it. I wonder if, with the current > > tooling in git, this could be done as a custom command... > > In that case, why not migrate Git to a new hash function instead > of adding a very niche fixup? Every day, for many years I find it maddening and really ridiculous that the Fedora package build process insists I provide it a tarball instead of being able to just fetch a signed git tag. Now while I haven't fought the battle to teach Fedora to actually use this, I think I have a pretty strong argument that git-evtag very clearly fulfills the same role that a signed tarball does. In particular, how a single checksum covers the entire source - no hash tree involved. The way that the evtag is "horizontal" across the source while the git tree is "vertical" around history means they're complementary. > See Documentation/technical/hash-function-transition.txt > for how to do it. evtag took me a day or two to write initially and doesn't impose any requirements on users except a small additional bit of software. In contrast, working on hash-function-transition.txt? That seems like it'd easily consume many person-months of work. And that plan only exists post-shatter.io, whereas git-evtag long predates both. > Personally I'd dislike to include ev-tags as it might send a signal > of "papering over sha1 issues instead of fixing it". I don't agree. I think it's pretty clear that a hash function transition would be a huge amount of work - not least because of course there are now at least two widely used implementations of git in C, plus https://www.eclipse.org/jgit/ plus... > push certificates are somewhat underdocumented, see the Why not call them "git signed pushes"? Junio's post even says "the signed push". And I just looked at this a little bit more but I'm not sure I see how this covers the same goal as evtags; it seems more about stopping someone from MITM my push to github.com, and not about ensuring integrity from someone pulling from github.com (and not wanting to fully trust github). ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: upstreaming https://github.com/cgwalters/git-evtag ? 2018-01-09 2:30 ` Colin Walters @ 2018-01-09 18:09 ` Santiago Torres 2018-01-09 20:38 ` Jonathan Nieder 0 siblings, 1 reply; 11+ messages in thread From: Santiago Torres @ 2018-01-09 18:09 UTC (permalink / raw) To: Colin Walters; +Cc: Stefan Beller, git [-- Attachment #1: Type: text/plain, Size: 2625 bytes --] > > See Documentation/technical/hash-function-transition.txt > > for how to do it. > > evtag took me a day or two to write initially and doesn't > impose any requirements on users except a small additional > bit of software. I agree that, in nature it shouldn't be difficult, but I also think that things usually take longer when you try to minimize code reuse and streamline the system's design. > In contrast, working on hash-function-transition.txt? That > seems like it'd easily consume many person-months of work. > And that plan only exists post-shatter.io, whereas git-evtag > long predates both. I think this is partly true. A hash transition has been brought up multiple times pre-shattered. In my opinion shattered was a much-needed PR push for SHA1 deprecation. In practice, things changed very little. > > Personally I'd dislike to include ev-tags as it might send a signal > > of "papering over sha1 issues instead of fixing it". > > I don't agree. I think it's pretty clear that a hash function transition > would be a huge amount of work - not least because of course > there are now at least two widely used implementations of git in C, > plus https://www.eclipse.org/jgit/ plus... I agree with Stefan here. I think it's better in the long-term to push for hash-agnosticity. I don't know if git-evtag is hash agnostic, but if it is not, then we have two transition plans to think about. > > > push certificates are somewhat underdocumented, see the > > Why not call them "git signed pushes"? Junio's post > even says "the signed push". A signed push creates a push certificate. > > And I just looked at this a little bit more but I'm not sure I > see how this covers the same goal as evtags; Correct me if I'm wrong (it's been a couple of years) but last time I read about git evtags, they basically did the following: 1. Create a signed tag. 2. Create a signed statement of all the references. 3. Create a checksum of the checked out code on the tag. 4. Create a tarball of it. I think 1) is already happening, 2) is very similar information to the one contained in a push certificate. I don't know how necessary are 3) and 4), but that's just my very opinionated take on it. Full disclosure, I published a "competing" solution a couple of years ago[1] but, in my personal opinion, I think push certificates can achieve the same security guarantees as my system with very little changes. Cheers! -Santiago. [1] https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: upstreaming https://github.com/cgwalters/git-evtag ? 2018-01-09 18:09 ` Santiago Torres @ 2018-01-09 20:38 ` Jonathan Nieder 2018-01-10 16:38 ` Santiago Torres 0 siblings, 1 reply; 11+ messages in thread From: Jonathan Nieder @ 2018-01-09 20:38 UTC (permalink / raw) To: Santiago Torres; +Cc: Colin Walters, Stefan Beller, git Hi, Santiago Torres wrote: >> In contrast, working on hash-function-transition.txt? That >> seems like it'd easily consume many person-months of work. >> And that plan only exists post-shatter.io, whereas git-evtag >> long predates both. > > I think this is partly true. A hash transition has been brought up > multiple times pre-shattered. In my opinion shattered was a much-needed > PR push for SHA1 deprecation. In practice, things changed very little. Sure, the main relevant things that changed are: 1. The sha1collisiondetection library became well known, which if anything makes moving off of SHA-1 *less* urgent than before (but still urgent). and 2. We came up with and agreed on a design for a transition off of SHA-1 that we are (slowly but surely) executing on. This means it's a good time to help get it done. >>> Personally I'd dislike to include ev-tags as it might send a signal >>> of "papering over sha1 issues instead of fixing it". >> >> I don't agree. I think it's pretty clear that a hash function transition >> would be a huge amount of work - not least because of course >> there are now at least two widely used implementations of git in C, >> plus https://www.eclipse.org/jgit/ plus... > > I agree with Stefan here. I think it's better in the long-term to > push for hash-agnosticity. I don't know if git-evtag is hash agnostic, > but if it is not, then we have two transition plans to think about. I don't think there's even a question here: Git has to transition off of SHA-1. In that context, Stefan's comment is a welcome one: once we've transitioned off of SHA-1, having a separate evtag feature would make git more complicated without any benefit to match. To put it another way, the gpgsig-sha256 field described in Documentation/technical/hash-function-transition.txt provides essentially the same functionality as an evtag. What's missing is an implementation of it. I'm happy to help in any way I can (reviews, advice, etc). [...] > Full disclosure, I published a "competing" solution a couple of years > ago[1] but, in my personal opinion, I think push certificates can > achieve the same security guarantees as my system with very little > changes. Work to improve the usability of push certs would also be very very welcome. Thanks and hope that helps, Jonathan > [1] https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: upstreaming https://github.com/cgwalters/git-evtag ? 2018-01-09 20:38 ` Jonathan Nieder @ 2018-01-10 16:38 ` Santiago Torres 0 siblings, 0 replies; 11+ messages in thread From: Santiago Torres @ 2018-01-10 16:38 UTC (permalink / raw) To: Jonathan Nieder; +Cc: Colin Walters, Stefan Beller, git [-- Attachment #1: Type: text/plain, Size: 1598 bytes --] > > push for hash-agnosticity. I don't know if git-evtag is hash agnostic, > > but if it is not, then we have two transition plans to think about. > > I don't think there's even a question here: Git has to transition off > of SHA-1. > > In that context, Stefan's comment is a welcome one: once we've > transitioned off of SHA-1, having a separate evtag feature would make > git more complicated without any benefit to match. To put it another > way, the gpgsig-sha256 field described in > Documentation/technical/hash-function-transition.txt provides > essentially the same functionality as an evtag. What's missing is an > implementation of it. > > I'm happy to help in any way I can (reviews, advice, etc). Same here, although I'm a bit swamped with other work... > > > Full disclosure, I published a "competing" solution a couple of years > > ago[1] but, in my personal opinion, I think push certificates can > > achieve the same security guarantees as my system with very little > > changes. > > Work to improve the usability of push certs would also be very very > welcome. I agree. I personally think that at least the sample hook work on here would be a good candidate for this[1], although I don't know what's the status of it. The way they are right now, they should at least warn when push certificates are not enabled on the server side (i.e., there is no hook to handle it). > > Thanks and hope that helps, > Jonathan No, thanks to you :) -Santiago. [1] https://public-inbox.org/git/20171202091248.6037-1-root@shikherverma.com/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-01-10 16:36 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-01-08 20:12 upstreaming https://github.com/cgwalters/git-evtag ? Colin Walters 2018-01-08 20:34 ` Johannes Schindelin 2018-01-08 20:40 ` Santiago Torres 2018-01-08 20:42 ` Colin Walters 2018-01-08 20:51 ` Santiago Torres 2018-01-08 20:49 ` Stefan Beller 2018-01-08 20:54 ` Santiago Torres 2018-01-09 2:30 ` Colin Walters 2018-01-09 18:09 ` Santiago Torres 2018-01-09 20:38 ` Jonathan Nieder 2018-01-10 16:38 ` Santiago Torres
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).