Nlnet funding for transitioning out of SHA-1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Nlnet funding for transitioning out of SHA-1

Raphaël Gomès
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
     - 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?

Thanks,
Raphaël

_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: Nlnet funding for transitioning out of SHA-1

Augie Fackler-2


> On Jan 15, 2020, at 11:53, Raphaël Gomès <[hidden email]> 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
> [hidden email]
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: Nlnet funding for transitioning out of SHA-1

Raphaël Gomès
On 1/16/20 9:38 PM, Augie Fackler wrote:
> I think overall that looks pretty good. Are you planning on making a submission?

Thanks for answer, sorry I took so long to get back to you.
It seems like we agree on the broad strokes, so let's go ahead.

I am indeed planning on doing the aforementioned work for the submission.

Here is the link to the public pad for everyone to contribute:
https://mypads.framapad.org/mypads/?/mypads/group/octobus-public-5d3rw470w/pad/view/mercurial-nlnet-sha1-em1tk979r

Note: I will be off Monday.

_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: Nlnet funding for transitioning out of SHA-1

Pierre-Yves David-2
On 1/24/20 2:37 PM, Raphaël Gomès wrote:
> On 1/16/20 9:38 PM, Augie Fackler wrote:
>> I think overall that looks pretty good. Are you planning on making a
>> submission?
>
> Thanks for answer, sorry I took so long to get back to you.
> It seems like we agree on the broad strokes, so let's go ahead.

The more I am thinking about it (helping Raphaël with the document), the
more I thinking that one of the most major roadblock we need to deal
with is the test suite. We have hundreds of thousand of line of test
file all relying on specific hash to be produced and consumed. We will
need to design a good way to express the used of different hash function
in tests. Otherwise we won't be able to seriously test the various hash
using options.

(not saying we need to solve that right now, but I expect it to be a
good chunk of the initial work).

> I am indeed planning on doing the aforementioned work for the submission.
>
> Here is the link to the public pad for everyone to contribute:
> https://mypads.framapad.org/mypads/?/mypads/group/octobus-public-5d3rw470w/pad/view/mercurial-nlnet-sha1-em1tk979r 
>
>
> Note: I will be off Monday.
>
> _______________________________________________
> Mercurial-devel mailing list
> [hidden email]
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: Nlnet funding for transitioning out of SHA-1

Augie Fackler-2
Honestly

> On Jan 24, 2020, at 11:29, Pierre-Yves David <[hidden email]> wrote:
>
> On 1/24/20 2:37 PM, Raphaël Gomès wrote:
>> On 1/16/20 9:38 PM, Augie Fackler wrote:
>>> I think overall that looks pretty good. Are you planning on making a submission?
>> Thanks for answer, sorry I took so long to get back to you.
>> It seems like we agree on the broad strokes, so let's go ahead.
>
> The more I am thinking about it (helping Raphaël with the document), the more I thinking that one of the most major roadblock we need to deal with is the test suite. We have hundreds of thousand of line of test file all relying on specific hash to be produced and consumed. We will need to design a good way to express the used of different hash function in tests. Otherwise we won't be able to seriously test the various hash using options.

Honestly I think I'd start by having a few small tests that exercise the basis with blake2b, then at some point we can set some tests to blake2b and some to sha1 and that'll be fine.

>
> (not saying we need to solve that right now, but I expect it to be a good chunk of the initial work).
>
>> I am indeed planning on doing the aforementioned work for the submission.
>> Here is the link to the public pad for everyone to contribute: https://mypads.framapad.org/mypads/?/mypads/group/octobus-public-5d3rw470w/pad/view/mercurial-nlnet-sha1-em1tk979r Note: I will be off Monday.
>> _______________________________________________
>> Mercurial-devel mailing list
>> [hidden email]
>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
> --
> Pierre-Yves David
> _______________________________________________
> Mercurial-devel mailing list
> [hidden email]
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: Nlnet funding for transitioning out of SHA-1

Pierre-Yves David-2


On 1/24/20 6:34 PM, Augie Fackler wrote:

> Honestly
>
>> On Jan 24, 2020, at 11:29, Pierre-Yves David <[hidden email]> wrote:
>>
>> On 1/24/20 2:37 PM, Raphaël Gomès wrote:
>>> On 1/16/20 9:38 PM, Augie Fackler wrote:
>>>> I think overall that looks pretty good. Are you planning on making a submission?
>>> Thanks for answer, sorry I took so long to get back to you.
>>> It seems like we agree on the broad strokes, so let's go ahead.
>>
>> The more I am thinking about it (helping Raphaël with the document), the more I thinking that one of the most major roadblock we need to deal with is the test suite. We have hundreds of thousand of line of test file all relying on specific hash to be produced and consumed. We will need to design a good way to express the used of different hash function in tests. Otherwise we won't be able to seriously test the various hash using options.
>
> Honestly I think I'd start by having a few small tests that exercise the basis with blake2b, then at some point we can set some tests to blake2b and some to sha1 and that'll be fine.

Yeah, starting with a smaller state to get the basic to run is probably
a good approach. However, soon enought we will need to exercise the full
test suite.

--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: Nlnet funding for transitioning out of SHA-1

Joerg Sonnenberger
In reply to this post by Raphaël Gomès
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
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: Nlnet funding for transitioning out of SHA-1

Augie Fackler-2
On Sun, Jan 26, 2020 at 3:04 PM Joerg Sonnenberger <[hidden email]> 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
> [hidden email]
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: Nlnet funding for transitioning out of SHA-1

Pierre-Yves David-2
In reply to this post by Joerg Sonnenberger


On 1/26/20 8:57 PM, Joerg Sonnenberger 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.
>
> 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 think it is important to not try to solve this questions while setting
up a grant request. The grant request should prepare time to think and
solves these questions, but that grant need to be finalized by Friday
(and Raphaël is Off today, (happy birthday Raphaël)). So we should plan
to solve theses questions, but not make it a pre-requires.

--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: Nlnet funding for transitioning out of SHA-1

Raphaël Gomès
In reply to this post by Raphaël Gomès
Hello again,

I think the current proposal is complete, I will re-read the entire
thing later tonight to be sure.

I plan on submitting tomorrow morning (Paris time) to leave the
opportunity for people in all time zones to get the notice in advance.

Thank you for helping,
Raphaël

On 1/15/20 5:53 PM, Raphaël Gomès 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
>     - 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?
>
> Thanks,
> Raphaël
>
> _______________________________________________
> Mercurial-devel mailing list
> [hidden email]
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: Nlnet funding for transitioning out of SHA-1

Raphaël Gomès
I just sent the proposal. I will keep you updated in this thread.

Thanks again for helping,
Raphaël

On 1/28/20 12:46 PM, Raphaël Gomès wrote:

> Hello again,
>
> I think the current proposal is complete, I will re-read the entire
> thing later tonight to be sure.
>
> I plan on submitting tomorrow morning (Paris time) to leave the
> opportunity for people in all time zones to get the notice in advance.
>
> Thank you for helping,
> Raphaël
>
> On 1/15/20 5:53 PM, Raphaël Gomès 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
>>     - 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?
>>
>> Thanks,
>> Raphaël
>>
>> _______________________________________________
>> Mercurial-devel mailing list
>> [hidden email]
>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
> _______________________________________________
> Mercurial-devel mailing list
> [hidden email]
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

Re: Nlnet funding for transitioning out of SHA-1

Raphaël Gomès
In reply to this post by Raphaël Gomès
Hello all,

I've received an email from Nlnet acknowledging our submission. It
should be reviewed within the next 3 weeks.

I'll keep you updated.

On 1/15/20 5:53 PM, Raphaël Gomès 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
>     - 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?
>
> Thanks,
> Raphaël
>
> _______________________________________________
> Mercurial-devel mailing list
> [hidden email]
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel