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

Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output

From
Stefan Beller <sbeller@google.com>
Date
Jun 6, 2017, 22:45 UTC
Message-ID
<CAGZ79kaYMR9uB0G911yRPXeZjbCeef2LHz4J2FLDOEj+mYkmqQ@mail.gmail.com>
In-Reply-To
<alpine.DEB.2.21.1.1706070008440.171564@virtualbox>

On Tue, Jun 6, 2017 at 3:22 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

>> Thanks for offering. ;-)
>
> Undoubtedly my lack of command of the English language is to blame for
> this misunderstanding.

Sometimes it is best to not be a native speaker, just fluent enough to get by. :)

> What I wanted to suggest instead was that the current direction looks very
> unfocused to me

That is unfortunate but reality of being a *real* community project. Neither you nor me (nor Junio) can command people to do things. The best we can do is reject an idea going off.

>, and that I do not see anything going forward in a
> coherent manner.
But is this bad?
> 1) this cannot be a one-person effort, it is too large

I agree. But there are efforts by multiple people. See Brians series (lots of different reviewers), also Brandon picked up parts of it (origin/bw/object-id). Or the design that was discussed on list, which was lots of people participation.

>
> 2) it cannot even be as uncoordinated an effort as it is now, because that
> leads only to bikeshedding instead of progress

Jonathan presented a list of things, that can be done in parallel in an uncoordinated effort, because that is how the project works. (C.f. he mentioned "rogue agents")

> 3) the only person who could make that call is Junio

Occasionally I think the same, but in fact it is not true. As said above, Junio has strong veto power for things going off rails, but in his role as a maintainer he does not coordinate people. (He occasionally asks them to coordinate between themselves, though)

>
> 4) we still have the problem that there is no cryptography expert among
> those who in the Git project are listened to

I can assure you that Jonathan listened to crypto experts. It just did not happen on the mailing list, which is sad regarding openness and transparency.

5. The timeline you seem to favor would be really great for people working
on Git at $BIG_CORP, as big corps usually plan things by the quarter. So maybe
by having a timeline (known in advance of the quarter) can convince managers
easier.
Show 15 quoted lines
>
>> How did you get the impression that their opinion had no impact? We have
>> been getting feedback about the choice of hash function both on and off
>> list from a variety of people, some indisputably security experts.
>> Sometimes the best one can do is to just listen.
>
> I did get the impression by talking at length to a cryptography expert who
> successfully resisted any suggestions to get involved in the Git mailing
> list.
>
> There were also accounts floating around on Twitter that a certain
> cryptography expert who dared to mention already back in 2005 how
> dangerous it would be to hardcode SHA-1 into Git was essentially shown the
> finger, and I cannot fault him for essentially saying "I told you so"
> publicly.

Heh. The community between 2005 and now has changed. (I was not there for example. ;-) ) So let's hope the community changes for the better.

Show 6 quoted lines
> In my mind, it would have made sense to ask well-respected cryptographers
> about their opinions and then try to figure out a consensus among them (as
> opposed to what I saw so far, a lot of enthusastic talk by developers with
> little standing in the cryptography community, mostly revolving around
> hash size and speed as opposed to security). And then try to implement
> that consensus in Git.

Sounds good to me. That is why I personally think point (4) from Jonathans list above over-emphasizes performance/size over security.

On the other hand if we find a smart way now, then this hash function transition will open the road to switching the hash function down the road once again with less or even no penalty if we make mistakes in choosing yet another bad hash function now.

Show 7 quoted lines
> Given my recent success rate with SHA-1 related
> concerns, I am unfortunately not the person who can bring that about.
>
> But maybe you are.
>
> Ciao,
> Dscho

Thanks for bringing the discussion back to life, Stefan

Previous: Brandon WilliamsNext: Jonathan Nieder
Message 22 of 59 in “Add regression tests for recent rebase -i fixes”
  1. 0/3 Add regression tests for recent rebase -i fixesPhillip Wood, May 31, 2017
  2. 3/3 rebase: Add tests for console output with conflicting stashPhillip Wood, May 31, 2017
  3. 1/3 rebase -i: Add test for reflog messagePhillip Wood, May 31, 2017
  4. Junio C HamanoJun 1, 2017
  5. 2/3 rebase: Add tests for console outputPhillip Wood, May 31, 2017
  6. Phillip WoodMay 31, 2017
  7. Junio C HamanoJun 1, 2017
  8. Johannes SchindelinJun 1, 2017
  9. Junio C HamanoJun 1, 2017
  10. Stefan BellerJun 1, 2017
  11. pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console outputJohannes Schindelin, Jun 2, 2017
  12. Jonathan NiederJun 2, 2017
  13. Jonathan NiederJun 2, 2017
  14. Ævar Arnfjörð BjarmasonJun 2, 2017
  15. Johannes SchindelinJun 15, 2017
  16. Junio C HamanoJun 3, 2017
  17. Johannes SchindelinJun 6, 2017
  18. Jonathan NiederJun 6, 2017
  19. Junio C HamanoJun 7, 2017
  20. t4005: modernize style and drop hard coded sha1Stefan Beller, Jun 7, 2017
  21. Brandon WilliamsJun 7, 2017
  22. Stefan BellerJun 6, 2017
  23. Jonathan NiederJun 6, 2017
  24. Samuel LijinJun 7, 2017
  25. Johannes SchindelinJun 7, 2017
  26. Stefan BellerJun 7, 2017
  27. Phillip WoodJun 7, 2017
  28. Junio C HamanoJun 9, 2017
  29. Phillip WoodJun 14, 2017
  30. Johannes SchindelinJun 14, 2017
  31. 0/3 Add regression tests for rectent rebase -i fixesPhillip Wood, Jun 14, 2017
  32. 1/3 rebase -i: Add test for reflog messagePhillip Wood, Jun 14, 2017
  33. 2/3 rebase: Add regression tests for console outputPhillip Wood, Jun 14, 2017
  34. 3/3 rebase: Add more regression tests for console outputPhillip Wood, Jun 14, 2017
  35. Johannes SchindelinJun 14, 2017
  36. Junio C HamanoJun 15, 2017
  37. Junio C HamanoJun 15, 2017
  38. Junio C HamanoJun 15, 2017
  39. Johannes SchindelinJun 16, 2017
  40. Johannes SixtJun 16, 2017
  41. Junio C HamanoJun 16, 2017
  42. Johannes SixtJun 19, 2017
  43. Junio C HamanoJun 19, 2017
  44. Phillip WoodJun 19, 2017
  45. Junio C HamanoJun 19, 2017
  46. Phillip WoodJun 19, 2017
  47. 0/4 Add regression tests for recent rebase -i fixesPhillip Wood, Jun 19, 2017
  48. 1/4 sequencer: print autostash messages to stderrPhillip Wood, Jun 19, 2017
  49. 2/4 rebase -i: Add test for reflog messagePhillip Wood, Jun 19, 2017
  50. 3/4 rebase: Add regression tests for console outputPhillip Wood, Jun 19, 2017
  51. 4/4 rebase: Add more regression tests for console outputPhillip Wood, Jun 19, 2017
  52. Junio C HamanoJun 23, 2017
  53. Junio C HamanoJun 23, 2017
  54. Phillip WoodJun 23, 2017
  55. Junio C HamanoJun 23, 2017
  56. Junio C HamanoJun 23, 2017
  57. Phillip WoodJun 26, 2017
  58. Junio C HamanoJun 23, 2017
  59. Phillip WoodJun 26, 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.