Nlnet funding for transitioning out of SHA-1
raf at durin42.com
Thu Jan 16 15:38:42 EST 2020
> On Jan 15, 2020, at 11:53, Raphaël Gomès <raphael.gomes at octobus.net> wrote:
> Hello all,
> As you all know, we have to transition out of using SHA-1 for Mercurial (https://www.mercurial-scm.org/wiki/SHA1TransitionPlan). While a known mitigation has been introduced by a few of Augie's patches, we still have to act on that transition.
> The Nlnet foundation has a program (https://nlnet.nl/PET/) for sponsoring privacy and trust enhancing technologies, category which this aspect of Mercurial falls into. Someone whose identity remains unclear came to the #mercurial IRC channel to tell us to send a submission.
> The latest "sha-mbles" attack is the stingy reminder that we need to take care of this before it is too late. Getting explicit funding is a great way to move forward and ensure Mercurial does not become a security liability in the near future.
> The deadline for submission is Feb 1st, so we have to move fast.
> The NLnet process is fairly light. Here are the things that we need think about as a community for this submission:
> - Project abstract (1200 chars)
> - The requested amount ranging from 5k to 50k€ (with details on how it is going to be spent).
> - Comparison with other efforts (probably a comparison with what git did)
> - Explanation of the technical challenges. Probably a mix of:
> - Mercurial is a 15 year old code base with strong compatibility guarantees
> - A smooth but secure transition is going to be hard
> The first step here is to sketch a high-level plan of the steps we need to take to transition out of SHA-1. The actual details (which algorithm, rehashing/compatibility, etc) can be dealt with while the work is actually being done.
> Right now I can see the following high level steps
> - Update the core code to be able to deal with multiple hashing functions
This should _mostly_ be work around handling 32-byte hashes instead of 20-byte ones.
> - Update the network protocol to deal with multiple hashing functions
I _believe_ the bundle format is already 32-byte savvy. If it's not, we'll do a changegroup4, I guess.
> - Update the on-disk format to deal with larger hashes
Already done! "revlogng" aka version 1 revlogs added this like...10 years ago. Probably longer. The only wrinkle I found in my audit last week was dirstate, and we can sidestep that for a while I think (just resolve the 20-byte hash on the changelog. It's not ideal, but it'll let us decouple the refactors.)
> - How to deal with backwards and forwards compatibility with regards to both repositories and client/server (wire protocol changes, etc.)
> - How changing hashing functions impacts the user experience (from additional steps to UI getting broken)
> - Help extensions to migrate if need be
> - Actually select a new hash function
Right now I'd say we should almost certainly use blake2b.
> Am I missing anything? How do you all feel about this?
I think overall that looks pretty good. Are you planning on making a submission?
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
More information about the Mercurial-devel