Re: Switching from SHA1 to a checksum type without known collisions in 1.15 working copy format

2022-12-29 Thread Karl Fogel

On 29 Dec 2022, Evgeny Kotkov wrote:

Karl Fogel  writes:


Now, how hard would this be to actually implement?


I plan to take a more detailed look at that, but I'm currently on 
vacation

for the New Year holidays.


That's great to hear, Evgeny.  In the meantime, enjoy your 
vacation!


Best regards,
-Karl


Re: Switching from SHA1 to a checksum type without known collisions in 1.15 working copy format

2022-12-29 Thread Branko Čibej

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


The case you're citing is specific to the repository, you could easily 
have a repository format that uses different hashes. The same for the RA 
layer, where we have capability negotiation; likewise for the WC. We'll 
always need compatibility with older formats, but a new enough client 
and server could use, e.g., SHA-256 or -512 all the way from WC to 
repository.


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?


On the other hand, there can be no "switching to" a new hash, because 
you don't know what the server actually supports -- hence, we'll always 
have to keep SHA-1 around. :) IMO Karl described one possible attack 
vector, and given the context (Wordpress...) it's probably only a matter 
of time before it happens.



-- Brane

Re: Switching from SHA1 to a checksum type without known collisions in 1.15 working copy format

2022-12-29 Thread Evgeny Kotkov via dev
Karl Fogel  writes:

> Now, how hard would this be to actually implement?

I plan to take a more detailed look at that, but I'm currently on vacation
for the New Year holidays.


Thanks,
Evgeny Kotkov