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

Re: Git and SHA-1 security (again)

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Jul 17, 2016, 14:21 UTC
Message-ID
<20160717142157.GA6644@vauxhall.crustytoothpaste.net>
In-Reply-To
<alpine.DEB.2.20.1607170949360.28832@virtualbox>
On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote:
> Out of curiosity: have you considered something like padding the SHA-1s
> with, say 0xa1, to the size of the new hash and using that padding to
> distinguish between old vs new hash?

I'm going to end up having to do something similar because of the issue of submodules. Submodules may still be SHA-1, while the main repo may be a newer hash. I was going to zero-pad, however. I was also, at least at first, going to force a separate .git dir for those, to avoid having to try to store two separate types of objects in the same repo.

The other limitation with this is that it isn't immediately obvious what hash is in use just because it has a certain length. For example, I plan on implementing SHA3-256, but it's also possible I might add BLAKE2b-256 for people for whom SHA3-256 is too slow. There's no way to distinguish between those two algorithms. Thus allowing multiple hashes in the same repo won't work without a format byte.

What I might do, however, is add multihash-style format information to the on-disk format for non-SHA-1 repos. Then SHA-1 compatibility could come in a future iteration. That would be compatible with the existing refactor.

Show 5 quoted lines
> I guess that it would also possible to introduce an opt-in "legacy mapper"
> which would generate a mapping locally of all objects' SHA-1 to whatever
> new hash you choose. Generating it locally would side-step the security
> issues of the SHA-1 algorithm. We would need to teach Git to pick that
> mapping up if available and use it, of course.

I think that might be easier. Considering the number of tests that hard-code object names, I might need that for the testsuite.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
Previous: Johannes SchindelinNext: Duy Nguyen
Message 6 of 52 in “Git and SHA-1 security (again)”
  1. Herczeg ZsoltJul 16, 2016
  2. brian m. carlsonJul 16, 2016
  3. Herczeg ZsoltJul 16, 2016
  4. brian m. carlsonJul 16, 2016
  5. Johannes SchindelinJul 17, 2016
  6. brian m. carlsonJul 17, 2016
  7. Duy NguyenJul 17, 2016
  8. brian m. carlsonJul 17, 2016
  9. Theodore Ts'oJul 17, 2016
  10. brian m. carlsonJul 17, 2016
  11. Junio C HamanoJul 18, 2016
  12. Jonathan NiederJul 18, 2016
  13. brian m. carlsonJul 18, 2016
  14. Johannes SchindelinJul 21, 2016
  15. Johannes SchindelinJul 21, 2016
  16. Junio C HamanoJul 22, 2016
  17. Johannes SchindelinJul 18, 2016
  18. brian m. carlsonJul 18, 2016
  19. Johannes SchindelinJul 21, 2016
  20. Duy NguyenJul 18, 2016
  21. Johannes SchindelinJul 19, 2016
  22. David LangJul 19, 2016
  23. Duy NguyenJul 19, 2016
  24. Junio C HamanoJul 19, 2016
  25. Duy NguyenJul 19, 2016
  26. Junio C HamanoJul 19, 2016
  27. Ævar Arnfjörð BjarmasonJul 18, 2016
  28. Herczeg ZsoltJul 18, 2016
  29. Ævar Arnfjörð BjarmasonJul 18, 2016
  30. Junio C HamanoJul 18, 2016
  31. Herczeg ZsoltJul 18, 2016
  32. David LangJul 18, 2016
  33. Fwd: Git and SHA-1 security (again)Herczeg Zsolt, Jul 18, 2016
  34. Johannes SchindelinJul 18, 2016
  35. Herczeg ZsoltJul 18, 2016
  36. Johannes SchindelinJul 18, 2016
  37. Duy NguyenJul 18, 2016
  38. Johannes SchindelinJul 19, 2016
  39. Duy NguyenJul 19, 2016
  40. David LangJul 19, 2016
  41. Duy NguyenJul 19, 2016
  42. David LangJul 19, 2016
  43. Duy NguyenJul 19, 2016
  44. Herczeg ZsoltJul 19, 2016
  45. Duy NguyenJul 20, 2016
  46. Johannes SchindelinJul 20, 2016
  47. Duy NguyenJul 20, 2016
  48. Stefan BellerJul 20, 2016
  49. Junio C HamanoJul 20, 2016
  50. Philip OakleyAug 22, 2016
  51. Herczeg ZsoltJul 18, 2016
  52. Johannes SchindelinJul 19, 2016

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.