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

Re: RFC v3: Another proposed hash function transition plan

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Sep 14, 2017, 18:49 UTC
Message-ID
<20170914184915.GC78683@aiede.mtv.corp.google.com>
In-Reply-To
<alpine.DEB.2.21.1.1709141119140.4132@virtualbox>
Johannes Schindelin wrote:
> On Wed, 13 Sep 2017, Jonathan Nieder wrote:
Show 12 quoted lines
>> As a side note, I am probably misreading, but I found this set of
>> paragraphs a bit condescending.  It sounds to me like you are saying
>> "You are making the wrong choice of hash function and everything else
>> you are describing is irrelevant when compared to that monumental
>> mistake.  Please stop working on things I don't consider important".
>> With that reading it is quite demotivating to read.
>
> I am sorry you read it that way. I did not feel condescending when I wrote
> that mail, I felt annoyed by the side track, and anxious. In my mind, the
> transition is too important for side tracking, and I worry that we are not
> fast enough (imagine what would happen if a better attack was discovered
> that is not as easily detected as the one we know about?).
Thanks for clarifying.  That makes sense.
[...]
Show 18 quoted lines
> As to *my* opinion: after reading https://goo.gl/gh2Mzc (is it really
> correct that its last update has been on March 6th?), my only concern is
> really that it still talks about SHA3-256 when I think that the
> performance benefits of SHA-256 (think: "Git at scale", and also hardware
> support) really make the latter a better choice.
>
> In order to be "ironed out", I think we need to talk about the
> implementation detail "Translation table". This is important. It needs to
> be *fast*.
>
> Speaking of *fast*, I could imagine that it would make sense to store the
> SHA-1 objects on disk, still, instead of converting them on the fly. I am
> not sure whether this is something we need to define in the document,
> though, as it may very well be premature optimization; Maybe mention that
> we could do this if necessary?
>
> Apart from that, I would *love* to see this document as The Official Plan
> that I can Show To The Manager so that I can ask to Allocate Time.
Sounds promising!

Thanks much for this feedback. This is very helpful for knowing what v4 of the doc needs.

The discussion of the translation table in [1] didn't make it to the doc. You're right that it needs to.

Caching SHA-1 objects (and the pros and cons involved) makes sense to mention in an "ideas for future work" section.

An implementation plan with well-defined pieces for people to take on and estimates of how much work each involves may be useful for Showing To The Manager. So I'll include a sketch of that for reviewers to poke holes in, too.

Another thing the doc doesn't currently describe is how Git protocol would work. That's worth sketching in a "future work" section as well.

Sorry it has been taking so long to get this out. I think we should have something ready to send on Monday.

Thanks, Jonathan

[1] https://public-inbox.org/git/CAJo=hJtoX9=AyLHHpUJS7fueV9ciZ_MNpnEPHUz8Whui6g9F0A@mail.gmail.com/
Previous: Brandon WilliamsNext: Philip Oakley
Message 88 of 113 in “RFC: Another proposed hash function transition plan”
  1. Jonathan NiederMar 4, 2017
  2. Linus TorvaldsMar 5, 2017
  3. brian m. carlsonMar 6, 2017
  4. Brandon WilliamsMar 6, 2017
  5. Which hash function to use, was Re: RFC: Another proposed hash function transition planJohannes Schindelin, Jun 15, 2017
  6. Mike HommeyJun 15, 2017
  7. Jeff KingJun 15, 2017
  8. Ævar Arnfjörð BjarmasonJun 15, 2017
  9. Johannes SchindelinJun 15, 2017
  10. Adam LangleyJun 15, 2017
  11. brian m. carlsonJun 15, 2017
  12. Ævar Arnfjörð BjarmasonJun 15, 2017
  13. brian m. carlsonJun 16, 2017
  14. Ævar Arnfjörð BjarmasonJun 16, 2017
  15. Johannes SchindelinJun 16, 2017
  16. Adam LangleyJun 16, 2017
  17. Junio C HamanoJun 16, 2017
  18. Junio C HamanoJun 16, 2017
  19. Jonathan NiederJun 16, 2017
  20. Ævar Arnfjörð BjarmasonJun 16, 2017
  21. Jeff KingJun 16, 2017
  22. Johannes SchindelinJun 19, 2017
  23. Mike HommeyJun 15, 2017
  24. Jeff KingJun 16, 2017
  25. Brandon WilliamsJun 15, 2017
  26. Junio C HamanoJun 15, 2017
  27. Jonathan NiederJun 15, 2017
  28. RFC v3: Another proposed hash function transition planJonathan Nieder, Mar 7, 2017
  29. Shawn PearceMar 9, 2017
  30. Jonathan NiederMar 9, 2017
  31. Jeff KingMar 10, 2017
  32. Jonathan NiederMar 10, 2017
  33. technical doc: add a design doc for hash function transitionJonathan Nieder, Sep 28, 2017
  34. Junio C HamanoSep 29, 2017
  35. Junio C HamanoSep 29, 2017
  36. Jonathan NiederSep 29, 2017
  37. Junio C HamanoOct 2, 2017
  38. Jason CooperOct 2, 2017
  39. Junio C HamanoOct 2, 2017
  40. Jason CooperOct 2, 2017
  41. Junio C HamanoOct 3, 2017
  42. Jason CooperOct 3, 2017
  43. Junio C HamanoOct 4, 2017
  44. Junio C HamanoSep 6, 2017
  45. Junio C HamanoSep 8, 2017
  46. Jeff KingSep 8, 2017
  47. Brandon WilliamsSep 11, 2017
  48. Johannes SchindelinSep 13, 2017
  49. demerphqSep 13, 2017
  50. Jonathan NiederSep 13, 2017
  51. Johannes SchindelinSep 14, 2017
  52. Jonathan NiederSep 14, 2017
  53. Johannes SchindelinSep 14, 2017
  54. Linus TorvaldsSep 13, 2017
  55. Johannes SchindelinSep 14, 2017
  56. Gilles Van AsscheSep 18, 2017
  57. Johannes SchindelinSep 18, 2017
  58. Gilles Van AsscheSep 19, 2017
  59. Johannes SchindelinSep 29, 2017
  60. Joan DaemenSep 29, 2017
  61. Johannes SchindelinSep 29, 2017
  62. Joan DaemenSep 30, 2017
  63. Johannes SchindelinOct 2, 2017
  64. Jonathan NiederSep 18, 2017
  65. Jason CooperSep 26, 2017
  66. Johannes SchindelinSep 26, 2017
  67. technical doc: add a design doc for hash function transitionStefan Beller, Sep 26, 2017
  68. Jonathan NiederSep 26, 2017
  69. Jonathan NiederSep 26, 2017
  70. Jason CooperOct 2, 2017
  71. Brandon WilliamsOct 2, 2017
  72. Jason CooperOct 2, 2017
  73. Linus TorvaldsOct 2, 2017
  74. Jeff KingOct 2, 2017
  75. Jonathan NiederSep 13, 2017
  76. Junio C HamanoSep 13, 2017
  77. Stefan BellerSep 13, 2017
  78. Jonathan NiederSep 13, 2017
  79. Junio C HamanoSep 14, 2017
  80. Johannes SchindelinSep 14, 2017
  81. demerphqSep 14, 2017
  82. Johannes SchindelinSep 14, 2017
  83. Junio C HamanoSep 13, 2017
  84. Jonathan NiederSep 13, 2017
  85. Junio C HamanoSep 14, 2017
  86. Johannes SchindelinSep 14, 2017
  87. Brandon WilliamsSep 14, 2017
  88. Jonathan NiederSep 14, 2017
  89. Philip OakleySep 15, 2017
  90. David LangMar 5, 2017
  91. Jonathan NiederMar 6, 2017
  92. Mike HommeyMar 7, 2017
  93. Jeff KingMar 6, 2017
  94. Junio C HamanoMar 6, 2017
  95. Jonathan TanMar 6, 2017
  96. Linus TorvaldsMar 6, 2017
  97. Brandon WilliamsMar 6, 2017
  98. Junio C HamanoMar 6, 2017
  99. Jeff KingMar 7, 2017
  100. Ian JacksonMar 7, 2017
  101. Linus TorvaldsMar 7, 2017
  102. Ian JacksonMar 8, 2017
  103. Johannes SchindelinMar 8, 2017
  104. Johannes SchindelinMar 8, 2017
  105. Use base32?Jason Hennessey, Mar 20, 2017
  106. Michael SteuerMar 20, 2017
  107. Jacob KellerMar 20, 2017
  108. Michael SteuerMar 21, 2017
  109. The Keccak TeamMar 13, 2017
  110. Jonathan NiederMar 13, 2017
  111. ankostisMar 13, 2017
  112. Johannes SchindelinMar 17, 2017
  113. Jeff KingMar 6, 2017

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.