On Sat, 2011-12-03 at 10:08 -0500, Jeff King wrote: > > > > Suppose I make the digest pluggable, something I intended to do > > eventually anyway? Then you just use the existing SHA-1 as an > > object identifier and the new digest in a signature chain? What I > > did was essentially to compute the new digest (using a CRC as the > > trivial case) whenever an object's SHA-1 hash is computed, plus > > using the new digest for low-cost collision checks. > > If you make the digest stronger (or pluggable) and include it in the > actual objects themselves, then you have a start on (2). > > I'd drop all of the digest-exchange bits from the protocol, as the > actual signatures are the real, trustable verification. I don't think > you can drop the external storage of the digests, which is one of the > ugliest bits. You'll be asking for the digests all the time to create > new commit objects, so you need to have it at hand without rehashing. The digest-exchange bits, including the tests and response to errors, is only 222 lines of new code, so its really a minor part. The rest takes care of what you referred to as "one of the ugliest bits," so I think it is useful to have available - you can then try various ways of improving the authentication of commit objects without having to do a lot of initial work. I can make those changes - probably over the next couple of weeks or so (have some other non-related things to take care of) and then send a new set of patches. > > And I wouldn't get my hopes up that this will go into git any time soon. > At this point, we're really guessing about how broken SHA-1 will be in > the future, and how much we are going to want to care. > > Just my two cents. Thanks for the discussion. I might add that it is not just a question of how broken SHA-1 is. If an IT department is considering adopting Git as the company's revision control system and authentication is important to the company, an IT manager may not accept SHA-1 for authentication purposes because NIST claims SHA-1 is not adequate for authentication in general and explaining to upper management why NIST's statement is not applicable given the way SHA-1 is used in Git is much harder than saying, "Git follows the current best practices regarding authentication." That statement is a simple check-list item one can show upper management in comparing alternatives. Such issues (making technical choices for non-technical reasons) have come up before - I once worked on a high-speed (for the time) networking project and our manager mentioned that transferring medical records such as X-ray pictures was one application - they do not accept lossy data compression because, even if it is completely adequate, in a malpractice suit, the plaintiff's lawyer would say, "And they purposely threw away data critical to my client's health," which would sound pretty damning to a typical jury. The legal risk outweighed the cost of the additional bandwidth. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html