On Thu, Feb 1, 2024 at 5:26 PM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote: > > Gentlemen, > > It seems you have both had your say in what flaws there has been in the > process. Can we please leave this part of the discussion and continue on the > technical issues? I'd hate for this discussion to turn to pie-throwing where > someone in the end feel offended and leave the community. We are such a small > community and we can't afford to lose someone just because an argument turns > toxic (it has happened before so let's make sure it doesn't happen again, > please).
I completely agree. Yes, there has been disagreement about process, but it is counterproductive to debate that anymore. Let's focus on the technical question and try to reach some consensus on what (if anything) to do. > As for the technical side, can we break down the current status and the > desired future status to some points and then look at what options we have > for solutions? > > Currently we use SHA1, which have known attacks. What are the risks? > - It has been argued that `svn st` will, especially with no-pristines, be > extra vulnerable to not detecting a modified file if someone can create a > collision with the checksum of the original file > - Someone also argued that a software could potentially be banned just > because it uses a checksum with a known attack, even if the checksum isn't > used in a security critical way. I was the one who spoke about that possibility. Just one example: NIST has already recommended federal agencies to stop using SHA-1 for "signatures and other operations threatened by collision attacks" and by 31 Dec 2030 NIST will publish "a revision of FIPS 180 that removes the SHA-1 specification" and "Modules that still use SHA-1 after 2030 will not be permitted for purchase by the federal government." All those quotes are taken from [1], which was one of the top hits in a recent DuckDuckGo search. (I don't remember the exact search.) Now, even if SVN's use cases of SHA1 are agreed by the developers to be completely safe, I think it is a real possibility that some sites could ban SVN because they consider SHA1 a banned algorithm, and even if we explain that SVN's use of SHA1 is completely safe, those explanations might not be acceptable in those settings, even if we are right. Given the way technology is used, understood, and sometimes (often?) misunderstood, I can imagine a ridiculous scenario in which Subversion could use 8-bit CRC, but not SHA1, even though SHA1 is much stronger than 8-bit CRC, just because SHA1 is "banned" and 8-bit CRC is not. > What options do we have and how do they mitigate the above risks?> - Evgeny > has already shown a possible solution with a salted hash (keeping SHA-1). > - Can we switch to another hash function completely and does it offer any > benefits compared to the salted SHA-1? > - Should we even do both? > > Any other points? > > Any thoughts? > > I would like to see this thread progress and I hope we can find consensus on > a way forward. > > Kind regards, > Daniel Sahlberg I, too, hope the community can come together and reach a consensus, whatever that ends up being. [1] https://www.securityweek.com/nist-retire-27-year-old-sha-1-cryptographic-algorithm/ Cheers, Nathan
