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

Gitorious should use CRC128 / 256 / 512 instead of SHA-1

From
Hans Petter Selasky <hps@selasky.org>
Date
Jan 13, 2023, 12:59 UTC
Message-ID
<39dd1a00-786b-acf5-8a40-2425f7dab6cc@selasky.org>
Hi,
Currently GIT only supports cryptographic hashes for its commit tags.
That means:
1) It's very difficult to edit the history without also recomputing the 
hash tags for all commits after the needed change-point, which then 
means references to a repository is broken.
2) Only a single bit error in the main repository can break everything!
3) Illicit contents may be present in binary blobs, which in the future 
may be need to be removed without warrant and the only way to do that is 
by rebasing and force pushing, which will break "everything". It can be 
everything from child-porn to expired distribution licenses.

Many people think that bit errors cannot happen because the memory uses ECC and the file system uses cryptographic hashes to verify the integrity of the data. But what many people forget about is that when copying data from memory to disk, typically using a DMA channel data is copied w/o any kind of integrity protection, because the integrity protection is not end-to-end. The integrity protection is only per-link.

Therefore I propose the following changes to GIT.
1) Use a CRC128 / 256 or 512 non-cryptographic based hashing algorithm 
as default.
2) Add support for a CRC fixup field, which usually is zero, but when 
merges are needed, it can be non-zero, to allow the hash-tag-value to 
remain the same! This also allows for easy conversion of existing GIT 
repositories to the new scheme.
3) All git objects should be uncompressed.

CRC-XXX can easily be used to correct multiple bit errors without any performance overhead.

Please CC me. I'm not subscribed to this list.
--HPS
Next: Konstantin Khomoutov
Message 1 of 26 in “Gitorious should use CRC128 / 256 / 512 instead of SHA-1”
  1. Hans Petter SelaskyJan 13, 2023
  2. Konstantin KhomoutovJan 13, 2023
  3. Hans Petter SelaskyJan 13, 2023
  4. rsbecker@nexbridge.comJan 13, 2023
  5. Hans Petter SelaskyJan 13, 2023
  6. Konstantin RyabitsevJan 13, 2023
  7. Hans Petter SelaskyJan 13, 2023
  8. rsbecker@nexbridge.comJan 13, 2023
  9. Hans Petter SelaskyJan 13, 2023
  10. Hans Petter SelaskyJan 13, 2023
  11. Konstantin RyabitsevJan 13, 2023
  12. Hans Petter SelaskyJan 13, 2023
  13. Hans Petter SelaskyJan 13, 2023
  14. Konstantin RyabitsevJan 13, 2023
  15. Hans Petter SelaskyJan 13, 2023
  16. Konstantin RyabitsevJan 13, 2023
  17. Hans Petter SelaskyJan 13, 2023
  18. Konstantin RyabitsevJan 13, 2023
  19. Hans Petter SelaskyJan 13, 2023
  20. Hans Petter SelaskyJan 13, 2023
  21. Konstantin RyabitsevJan 13, 2023
  22. Hans Petter SelaskyJan 13, 2023
  23. Hans Petter SelaskyJan 13, 2023
  24. Philip OakleyJan 13, 2023
  25. Konstantin RyabitsevJan 13, 2023
  26. Konstantin KhomoutovJan 13, 2023

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.