Nlnet funding for transitioning out of SHA-1

Augie Fackler 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?

> 
> Thanks,
> Raphaël
> 
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel



More information about the Mercurial-devel mailing list