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

From: Santiago Torres <santiago@nyu.edu>
Date: Jan 9, 2018, 18:09 UTC
Message-ID: <20180109180933.jbyidmmv5xpsjuae@LykOS.localdomain>
In-Reply-To: <1515465051.2895186.1228754952.0036D645@webmail.messagingengine.com>

Show 6 quoted lines

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

Show 7 quoted lines

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

Show 5 quoted lines

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