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).
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. 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 Den tors 18 jan. 2024 kl 14:36 skrev Evgeny Kotkov via dev < dev@subversion.apache.org>: > Daniel Shahaf <d...@daniel.shahaf.name> writes: > > > Procedurally, the long hiatus is counterproductive. > > This reminds me that the substantive discussion of your veto ended with my > email from 8 Feb 2023 that had four direct questions to you and was left > without an answer: > > `````` > > That's not how design discussions work. A design discussion doesn't go > > "state decision; state pros; implement"; it goes "state problem; > discuss > > potential solutions, pros, cons; decide; implement" (cf. [4, 5, 6]). > > Well, I think it may not be as simple as it seems to you. Who decided > that > we should follow the process you're describing? Is there a thread with a > consensus on this topic? Or do you insist on using this specific process > because it's the only process that seems obvious to you? What > alternatives > to it have been considered? > > As far as I can tell, the process you're suggesting is effectively a > waterfall-like process, and there are quite a lot of concerns about its > effectiveness, because the decisions have to be made in the conditions of > a lack of information. > `````` > > It's been more than 11 months since that email, and those questions still > don't have an answer. So if we are to resume this discussion, let's do it > from the proper point. > > > You guys are welcome to try to /convince/ me to change my opinion, or to > > have the veto invalidated. In either case, you will be more likely to > > succeed should your arguments relate not only to the veto's implications > > but also to its /sine qua non/ component: its rationale. > > Just in case, my personal opinion here is that the veto is invalid. > > Firstly, based on my understanding, the ASF rules prohibit casting a veto > without an appropriate technical justification (see [1], which I personally > agree with). Secondly, it seems that the process you are imposing hasn't > been > accepted in this community. As far as I know, this topic was tangentially > discussed before (see [2], for example), and it looks like there hasn't > been > a consensus to change our current Commit-Then-Review process into some > sort of Review-Then-Commit. > > (At the same time I won't even try to /convince/ you, sorry.) > > [1] https://www.apache.org/foundation/voting.html > [2] https://lists.apache.org/thread/ow2x68g2k4lv2ycr81d14p8r8w2jj1xl > > > Regards, > Evgeny Kotkov >
