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

[Jonathan Nieder <jrnieder@gmail.com>]

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