Skip to content

Latest commit

 

History

History
181 lines (143 loc) · 10.6 KB

2018-07-18-edition-41.markdown

File metadata and controls

181 lines (143 loc) · 10.6 KB
title layout date author categories navbar
Git Rev News Edition 41 (July 18th, 2018)
default
2018-07-18 12:06:51 +0100
chriscool
news
false

Git Rev News: Edition 41 (July 18th, 2018)

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.

Discussions

General

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.

Releases

Other News

Various

Light reading

Git tools and sites

  • GitRuler - Automated checking of the status of a repository, like unit testing for a git repo (that repo has specific state)
  • Gitgraph.js is a simple JavaScript library meant to help you visually presenting git branching models, using HTML canvas
  • diffoscope: in-depth comparison of files, archives, and directories (will recursively unpack archives of many kinds and transform various binary formats into more human readable form)
  • gitfiti is a tool for crafting graffiti in a GitHub commit history calendar; includes list of notable derivatives
  • GitLab Pages: websites for your GitLab projects, user account or group
  • A new archive of linux-kernel mailing list (LKML) posts going back to 1998 is now available at lore.kernel.org, which is based on public-inbox (with Git-backed archival mechanism you can clone and pull)

Credits

This edition of Git Rev News was curated by Christian Couder <[email protected]>, Jakub Narębski <[email protected]>, Markus Jansen <[email protected]> and Gabriel Alcaras <[email protected]> with help from Luca Milanesio and Derrick Stolee.