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

Re: [IGNORETHIS/PATCH] Choosing the sha1 prefix of your commits

From
Jeff King <peff@peff.net>
Date
Oct 20, 2011, 15:56 UTC
Message-ID
<20111020155611.GB16114@sigill.intra.peff.net>
In-Reply-To
<20111020131454.GB7464@thunk.org>
On Thu, Oct 20, 2011 at 09:14:55AM -0400, Ted Ts'o wrote:
> Another possibility is to warn if the commit messages are not NULL
> terminated.

A minor nit, but it's not whether they are terminated with NUL, but rather whether they have embedded NUL. But yeah, this could maybe just be something fsck looks for.

Show 7 quoted lines
> Note though that if we're really worried about a bad guy trying to
> attack us with a hash collision, he/she could always use "invisible"
> non-printing characters in the commit message, and/or just mess with
> one or both of the timestamps.  The more bits and more degrees of
> flexibility the attacker has, the easier it would be, of course.  In
> the grand scheme of things it's not clear to me how big of a deal this
> would be.

Good point. Append-only attacks are cheaper, because you can avoid doing most of the hash computation on each iteration (like my patch does). But that's not a big-O speedup, it just makes the constant smaller. So you could assume that any feasible appending attack would probably become feasible for recomputing the full hash eventually.

Show 8 quoted lines
> If people were really concerned it would probably be easier to use
> backup crypto checksum using something stronger (say, SHA-2 or the
> eventual SHA-3).  Just store the backup checksums of the parent
> commitments in some backwardly compatible place that old git
> implementations wouldn't look (say, after the NULL in the commit
> message if there isn't a better place :-), and new implementations
> would know to generate the checksums, and old implementations would
> ignore it.

Yeah, if birthday attacks against sha1 become possible, the sensible thing is probably not to worry too much about the file format, but to use a better hash.

Commits can hide extra hashes in a header pretty easily. But what about trees and blobs? I don't think there's any "ignored" space in either one.

-Peff
Previous: Ted Ts'oNext: Drew Northup
Message 15 of 24 in “Choosing the sha1 prefix of your commits”
  1. Choosing the sha1 prefix of your commitsÆvar Arnfjörð Bjarmason, Oct 19, 2011
  2. Jeff KingOct 19, 2011
  3. Jeff KingOct 19, 2011
  4. Jeff KingOct 20, 2011
  5. Kyle MoffettOct 20, 2011
  6. Jeff KingOct 20, 2011
  7. Junio C HamanoOct 20, 2011
  8. Kyle MoffettOct 20, 2011
  9. Jeff KingOct 24, 2011
  10. Junio C HamanoOct 20, 2011
  11. Jeff KingOct 20, 2011
  12. Junio C HamanoOct 20, 2011
  13. Jeff KingOct 20, 2011
  14. Ted Ts'oOct 20, 2011
  15. Jeff KingOct 20, 2011
  16. Drew NorthupOct 25, 2011
  17. Re* [IGNORETHIS/PATCH] Choosing the sha1 prefix of your commitsJunio C Hamano, Oct 20, 2011
  18. Jeff KingOct 20, 2011
  19. Nguyen Thai Ngoc DuyOct 20, 2011
  20. Nguyen Thai Ngoc DuyOct 20, 2011
  21. Jeff KingOct 20, 2011
  22. Mikael MagnussonOct 20, 2011
  23. Elijah NewrenOct 20, 2011
  24. Jonathan NiederOct 19, 2011

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.