Nlnet funding for transitioning out of SHA-1

Augie Fackler raf at durin42.com
Sun Jan 26 20:37:42 EST 2020


On Sun, Jan 26, 2020 at 3:04 PM Joerg Sonnenberger <joerg at bec.de> wrote:
>
> 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.

This has come up on IRC, and I'm still -1 on (2): it is, in my view,
an *anti-goal* to grant old clients transparent access to new-hash
commits. That will inevitably lead to downgrade attacks.

>
> 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.

I don't oppose secondary identifiers, I guess. But I have seen it done
poorly at least twice (most notably in Veracity) and never seen it
done well. I think this notion needs more motivation to justify the
(in my mind) higher engineering cost it implies.

>
> Joerg
> _______________________________________________
> 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