git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Jan 9, 2018, 20:38 UTC
Message-ID
<20180109203849.GA30468@aiede.svl.corp.google.com>
In-Reply-To
<20180109180933.jbyidmmv5xpsjuae@LykOS.localdomain>
Hi,
Santiago Torres wrote:
Show 8 quoted lines
>> 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.
Show 11 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.

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
Previous: Santiago TorresNext: Santiago Torres
Message 10 of 11 in “upstreaming https://github.com/cgwalters/git-evtag ?”
  1. Colin WaltersJan 8, 2018
  2. Johannes SchindelinJan 8, 2018
  3. Santiago TorresJan 8, 2018
  4. Colin WaltersJan 8, 2018
  5. Santiago TorresJan 8, 2018
  6. Stefan BellerJan 8, 2018
  7. Santiago TorresJan 8, 2018
  8. Colin WaltersJan 9, 2018
  9. Santiago TorresJan 9, 2018
  10. Jonathan NiederJan 9, 2018
  11. Santiago TorresJan 10, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.