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
