On Tue, Dec 30, 2025 at 1:45 PM Evgeny Kotkov via dev <[email protected]> wrote: > > Daniel Shahaf <[email protected]> writes: > > > My veto there was a rather rare beast: I wasn't vetoing a design decision > > ("This should use a port number higher than 1024 so it doesn't need to be > > launched as uid 0") but a design process, or rather, the lack of > > /on-list/ /consensus-based/ design process. > > The lack of using an appropriate design process in this case may be > subjective, as indicated in [1]. > > You also insisted that we should use a specific form of the design > process [2]. But I don't recall a thread with consensus on the fact > that we should be using it, and my question about it was left unanswered. > > > Anyway, looking up the dates reminded me we should get started on organizing > > the veto's third birthday party. > > I'd like to remind that the meaningful discussion of your veto ended twice > with my emails from 8 Feb 2023 and Jan 18 2024 that had direct questions > to you and were both left without an answer — for a year and for two years, > respectively. > > [1]: https://lists.apache.org/thread/4bnwxz37jkjlltry425kd3qovygcvrgk > [2]: https://lists.apache.org/thread/3xsvcs278slqyd25dkg7ztmr2lfp76xv > > > Regards, > Evgeny Kotkov
I think what is really missing here is a clear analysis of the *problem*. What problem are we trying to solve? Daniel mentioned this early in the discussion (before the veto-card was put on the table) [1], [2]. Without a clear description of the problem it's hard to discuss the design and alternative solutions, because ... solutions to what? So that, to me, is the underlying reason why the discussion derailed to the point of a veto. So, what really is the problem with SHA1 as used in a (pristines-on-demand or even regular) working copy? Since the pod-feature sparked the entire discussion, it must be something that is a bigger problem in pod-WCs, right? In [3] Karl gave an argument explaining why the loss of guarantee by SHA1 (i.e. there being known collisions) is enough justification by itself. But nowhere in his argument did he imply that the problem is worse in pod-WCs. Evgeny didn't give a clear "worse in pod-WCs" argument either, except "it would introduce additional cases where a working copy currently relies on comparing checksums" [4]. He did argue in the same email that the pod-feature might simply be a good opportunity to switch to a different checksum type. But is this enough? Does this really express "there is a problem, it is X, and we should solve it (now)"? I've been wondering what an attack might look like that gets possible if SHA1 would get fully broken (for instance with a preimage attack [5], i.e. for a given hash the attacker is able to create a malicious file with the same hash), and which would be mitigated by switching checksum types. As in Karl's example [3], an attacker might be able to put a malicious file in a particular working copy (e.g. on a server that runs from a checkout), which is undetectable by 'svn st' et al. That would be bad. However: - I don't think pristines-on-demand makes a difference here. - If we'd switch to salted SHA1, the attacker (having access to the WC) could first steal the salt from wc.db, and then use it when forging his collision, right? Switching to SHA256 would be a better option then. - If the attacker has write access to the WC, couldn't he just as easily modify wc.db and/or the pristines directory to sneak his file in undetectably? That would probably be easier than to create a SHA1 collision. So, I guess I too remain unconvinced that SHA1 being broken exposes us to new, actual risks that can be addressed by switching to a new checksum type. OTOH we shouldn't remain stuck on an old checksum type forever just because we don't want to make changes (I know, every change introduces risk and new bugs, so there is a always a balance). All in all it might make sense to make it *possible* to switch checksum types in the WC, so if that's all the pristine-checksum-salt does, it might well be worth it. But then the problem description is more like: "our WC checksum is hardcoded to SHA1, and we want this to be more flexible and give the user a choice". (why? maybe some users may want to have control over this? we want to be able to let users switch quickly if the need arises? hm ... still no _big_ justification, but I could live with it) [1] https://lists.apache.org/thread/ovzbsvor5mr67lsfy7pl9oj86vthozgp [2] https://lists.apache.org/thread/lnr06v7xxn3mxpcnbshx85dqrlkpkjlw [3] https://lists.apache.org/thread/k0yvd4d5zgr05k1syc8p56xbzd529c9p [4] https://lists.apache.org/thread/cq9q43qb3774kb853qcmnml9zd68dyj3 [5] https://en.wikipedia.org/wiki/Preimage_attack Cheers, -- Johan
