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

[Santiago Torres <santiago@nyu.edu>]

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