On 29 Jan 2023, Evgeny Kotkov via dev wrote:
I have *absolutely* no idea where "being railroaded through" comes from. Really, it's a wrong way of portraying and thinking about the events that have
happened so far.

Reiterating over those events: I wrote an email containing my thoughts and explaining the motivation for such change. I didn't reply to some of the questions (including some tricky questions, such as the one featuring a theoretical hash function), because they have been at least partly answered by others in the thread, and I didn't have anything valuable
to add at that time.

During that time, I was actively coding the core part of the change, to check if it's possible technically. Which is important, as far as I believe, because not all theoretically possible solutions can be implemented without facing significant practical or implementation-related issues, and it seems to me that you significantly undervalue such an approach.

I do not say my actions were exemplary, but as far as I can tell, they're pretty much in line with how svn-dev has been operating so far. But, it all resulted in an unclear veto without any _technical_ arguments, where what's being vetoed is unclear as well, because the change was not ready at the
moment veto got casted.

And because your veto goes in favor of a specific process (considering that no other arguments were given), the only thing that's *actually* being railroaded is an odd form of an RTC (review-then-commit) process that is against our usual CTR (commit-then-review) [1,2]. That's railroading, because it hasn't been explicitly discussed anywhere and a consensus
on it has not been reached.

Daniel, given what's in Evgeny's branch now, could you summarize your current technical objections if any?

If they are something like "This code is solving the wrong problem(s)" or "I'm not sure what problem(s) it's supposed to solve", those count as technical objections. It's just that it would be useful to have the objection(s) gathered in one place. This thread has been long and somewhat digressive -- I'm not saying that's due to you -- and I at least have found it a bit difficult to keep track of the concrete objections versus various interesting but ultimately theoretical points.

The reason I'm supportive of Evgeny's direction is that his changes, if completed, would offer a solution to the (admittedly still somewhat distant) security concern I raised early on. Essentially, I'm worried that second-preimage attacks on SHA-1 are coming eventually (maybe I'm wrong about this -- they are after all significantly harder than mere collision attacks). *If* such attacks become possible, then our WC could report a file as unmodified when in fact it is modified, which would have real security implications, as I outlined.

Like I said, this is far from urgent, and IMHO it certainly should not delay a release of our new pristineless feature. But when and if Evgeny's branch is ready (where "ready" presumably includes something other than salted SHA-1 as the other checksum option), I would like to see these changes go in, unless we identify some harm from them.

For everyone's ease of reference:

$ svn cat https://svn.apache.org/repos/asf/subversion/branches/pristine-checksum-kind/BRANCH-README

$ svn log --stop-on-copy https://svn.apache.org/repos/asf/subversion/branches/pristine-checksum-kind/

Best regards,
-Karl

Reply via email to