Welcome to the 41st edition of Git Rev News, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page on git.github.io.
This edition covers what happened during the month of June 2018.
Brian Carlson, who has been working for a long time on improving Git code to make it easier to support replacing SHA-1 with a new hash function, recently posted an update and invited people to discuss the future steps in this area.
As the new hash function is still undecided (see below), it is called “NewHash” by everyone for now. It is expected though that it will be a 256-bit hash algorithm while SHA-1 is 160-bit, and this change alone has required a lot of internal work.
With Brian’s latest patches Git would work using NewHash, including passing the test suite, though it would be incompatible with current Git.
As the hash function transition plan tells that a Git using NewHash should be able to communicate through fetching and pushing with a Git using SHA-1, the next step is to implement such kind of communication and that’s what Brian started to do.
Technically the work consists in porting everything to use a variable
called the_hash_algo that will store information about the current
hash algorithm.
After describing other technical details related to his work and recommending ways to make current developments compatible with it, Brian suggested resuming the discussion about what NewHash should actually be, as he will need to actually use a new hash when writing objects to disk.
Brian then proposed to send to the list an analysis he made on “availability of implementations, performance, and other attributes described in the transition plan”.
Ævar Arnfjörð Bjarmason, Jonathan Nieder and Duy Nguyen all replied separately to Brian to congratulate him for his work, to discuss a few technical details, and to welcome his analysis of the possible hash functions.
Brian replied to them by sending his Hash algorithm analysis to the mailing list. The conclusion from this document is that the best is one of SHA-256, SHA-3-256 and BLAKE2b depending on the goals (security, performance, availability).
Jonathan replied to this analysis by asking technical questions and summarizing the previous discussions. He said that Yves Orton and Linus Torvalds prefer SHA-3 over SHA-2 because of how it is constructed, though a number of knowledgeable people suggested K12 instead of SHA-3 for performance reasons, while Johannes Schindelin, alias Dscho, strongly prefers SHA-256 because it is well known, widely available and fast.
Linus replied to this summary by explaining that “SHA-2 has the exact same weak inter-block state attack” as SHA-1, and it would be crazy to “go with a crypto choice that has that known weakness”. About performance he thinks that “‘256-bit hashes are bigger’ is going to be the more noticeable performance issue” and that K12 “should be a front-runner” as it was suggested by the Keccak people.
There were further discussions involving Ævar, Linus, David Lang, Brian, Dscho and also Gilles Van Assche who co-created Keccak which then became SHA-3, but there was still no consensus and no decision has been made.
Various
A Git standup on IRC every two weeks at 17:00-17:30 UTC has been announced by Jonathan Nieder.
Derrick Stolee has written about Commit Graph on Microsoft DevOps Blog:
Echoes of Microsoft acquring GitHub (see Git RevNews Edition #40)
Light reading
Git tools and sites
This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Jakub Narębski <jnareb@gmail.com>, Markus Jansen <mja@jansen-preisler.de> and Gabriel Alcaras <gabriel.alcaras@telecom-paristech.fr> with help from Luca Milanesio and Derrick Stolee.