On 28 Dec 2022, Branko Čibej wrote:
My point was that we shouldn't have to worry about format bumps as
much any more because we have infrastructure in the client for
supporting multiple WC formats. That includes optional pristines,
different hashes, compressed pristines, etc. etc.

Thank you for the reminder -- that is indeed important here.

On 28 Dec 2022, Daniel Sahlberg wrote:
Since we need to be backwards compatible with older v1 clients, can
this check ever be removed (before Subversion 2)?

So, while I believe f32 is a good opportunity to switch to a new
hash, what is the problem we would like to solve with a new hash?

As I said before, even if we couldn't think of a concrete problem right now, the mere fact that a former guarantee [1] has become a non-guarantee is enough motivation. We can't anticipate all the problems that might arise from people being able to craft local content that looks unmodified to Subversion. (As you implied, r1794611 has no effect for content that is never committed to the repository.)

Of course, my saying "This matters just through reasoning from first principles, therefore we should fix it" would count for a lot more if I were volunteering to fix it, which I'm not alas. But I do think we don't need to search further for justifications. What we already know is enough: our hash algorithm is known to be collidable, yet what we're using it for depends on non-collidability; therefore, switching to a better algorithm is a good idea.

However, it needn't be a blocker for the next release, for the reason Brane gave.

Best regards,
-Karl

[1] "Former guarantee" meaning "former guarantee for all practical purposes", of course, since in the past there weren't ways to make collisions happen.

Reply via email to