upstreaming https://github.com/cgwalters/git-evtag ?

upstreaming https://github.com/cgwalters/git-evtag ?

[Colin Walters]

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?  

Re: upstreaming https://github.com/cgwalters/git-evtag ?

[Johannes Schindelin]

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

Re: upstreaming https://github.com/cgwalters/git-evtag ?

[Santiago Torres]

[-- 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 --]

Re: upstreaming https://github.com/cgwalters/git-evtag ?

[Colin Walters]

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) 

Re: upstreaming https://github.com/cgwalters/git-evtag ?

[Stefan Beller]

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

Re: upstreaming https://github.com/cgwalters/git-evtag ?

[Santiago Torres]

[-- 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 --]

Re: upstreaming https://github.com/cgwalters/git-evtag ?

[Santiago Torres]

[-- 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 --]

Re: upstreaming https://github.com/cgwalters/git-evtag ?

[Colin Walters]

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

Re: upstreaming https://github.com/cgwalters/git-evtag ?

[Santiago Torres]

[-- 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 --]

Re: upstreaming https://github.com/cgwalters/git-evtag ?

[Jonathan Nieder]

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

Re: upstreaming https://github.com/cgwalters/git-evtag ?

[Santiago Torres]

[-- 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 --]