On Thu, May 03, 2012 at 07:25:12PM +0200, Thomas Gummerer wrote: > 160-bit object name for the object that would result from writing > this span of index as a tree. Would now be a fun time to bring up the idea of eventually migrating away from 160-bit hashes? I love to keep reminding people that SHA-1 is showing its age[1]. Even if we don't add support for variable length hashes at this point, it would be nice to at least have the code written in a relatively hash-length-independent way, such that someone could come along and make a new, very similar, format without rewriting much of the code. If there is going to be support for different hash algorithms, or even different length hashes, we need space in the file (before the first hash, obviously) to indicate what we're using; currently reserved. For this, we need to decide on how we're going to store the algorithm; my guesses would be either: * a (1-octet) enum, like tls (0: sha1/160, 1: sha2-256/160 [sha2's 256-bit mode truncated to 160-bits using a recommended truncation mode], 2: keccak-512, etc.); stopping at 127 (i.e. reserving the high-bit for future use), or * a lowascii string, with prefixed 1 (or 2?)-octet length, like ssh, using the above format. If people believe that the chance of this being implemented (within the lifespan of v5) is tiny, this octet can be reserved; i.e. a zero-length string means sha1/160. tl;dr: Please reserve one or more octet(s) early on for the details of the hash, and think about people who want more than 20/40 octets available when implementing it. -- Chris West (FauxFaux). [1]: http://csrc.nist.gov/groups/ST/hash/policy.html "...and must use the SHA-2 family of hash functions for these applications after 2010." -- 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