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

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?  

Hi,

On Mon, 8 Jan 2018, Colin Walters wrote:

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.

I have no opinion, I was just curious what this otherwise undescribed thing was about.

Ciao, Johannes

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:

On Mon, Jan 8, 2018, at 3:40 PM, Santiago Torres wrote:

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)

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 12:40 PM, Santiago Torres <santiago@nyu.edu> wrote:

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

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

On Mon, Jan 8, 2018, at 3:49 PM, Stefan Beller wrote:

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.
 

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.

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

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

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.

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.

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.

A signed push creates a push certificate.

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

Hi,

Santiago Torres wrote:

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.

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

[...]

Work to improve the usability of push certs would also be very very welcome.

Thanks and hope that helps, Jonathan

Same here, although I'm a bit swamped with other work... 

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

No, thanks to you :)

-Santiago.

[1] https://public-inbox.org/git/20171202091248.6037-1-root@shikherverma.com/