Nlnet funding for transitioning out of SHA-1

Joerg Sonnenberger joerg at bec.de
Sun Jan 26 14:57:04 EST 2020


On Wed, Jan 15, 2020 at 05:53:06PM +0100, Raphaël Gomès wrote:
> Right now I can see the following high level steps
> 
>     - Update the core code to be able to deal with multiple hashing
> functions
>     - Update the network protocol to deal with multiple hashing functions
>     - Update the on-disk format to deal with larger hashes
>     - 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
> 
> Am I missing anything? How do you all feel about this?

I'd like to take a step back and start from the needs to be supported.

(1) It must be possible to create a new repository that uses a modern
cryptographic hash function both on-disk and when communicating with
other servers.

(2) It must be possible to migrate an existing repository without
invalidating references to commits. It should allow as much
interoperability with old wire clients as possible, at the very least pull
support and optionally write support. It should not be necessary to
support direct repository access from old clients. It must be possible
to schedule the migration on the timeframe of the user, not enforced as
part of an update.

The most important implication is that we need to get support for
secondary identifiers. That's the one big part currently missing in
revlog. With that in place, a lot of the other things follow as they can
transparently convert old and new node references.

Joerg


More information about the Mercurial-devel mailing list