Daniel Shahaf <d...@daniel.shahaf.name> writes: > > I can complete the work on this branch and bring it to a production-ready > > state, assuming there are no objections. > > Your assumption is counterfactual: > > https://mail-archives.apache.org/mod_mbox/subversion-dev/202301.mbox/%3C20230119152001.GA27446%40tarpaulin.shahaf.local2%3E > > https://mail-archives.apache.org/mod_mbox/subversion-dev/202212.mbox/%3CCAMHy98NqYBLZaTL5-FAbf24RR6bagPN1npC5gsZenewZb0-EuQ%40mail.gmail.com%3E
I don't see any explicit objections in these two emails (here I assume that if something is not clear to a PMC member, it doesn't automatically become an objection). If the "why?" question is indeed an objection, then I would say it has already been discussed and responded to in the thread. Now, returning to the problem: As described in the advisory [1], we have a supported configuration that makes data forgery possible: - A repository with disabled rep-sharing allows storing different files with colliding SHA-1 values. - Having a repository with disabled rep-sharing is a supported configuration. There may be a certain number of such repositories in the wild (for example, created with SVN < 1.6 and not upgraded afterwise). - A working copy uses an assumption that the pristine contents are equal if their SHA-1 hashes are equal. - So committing different files with colliding SHA-1 values makes it possible to forge the contents of a file that will be checked-out and used by the client. I would say that this state is worrying just by itself. However, with the feasibility of chosen-prefix attacks on SHA-1 [2], it's probably only a matter of time until the situation becomes worse. That could happen after a public disclosure of a pair of executable files/scripts where the forged version allows for remote code execution. Or maybe something similar with a file format that is often stored in repositories and that can be executed or used by a build script, etc. [1] https://subversion.apache.org/security/sha1-advisory.txt [2] https://sha-mbles.github.io/ Speaking of the proposed switch to SHA-256 or a different checksum, there's an argument by contradiction: if we were designing the pristineless working copy from scratch today, would we choose SHA-1 as the best available hash that can be used to assert content equality? If yes, how can one prove that? > Objections have been raised, been left unanswered, and now implementation > work has commenced following the original design. That's not acceptable. > I'm vetoing the change until a non-rubber-stamp design discussion has > been completed on the public dev@ list. I would like to note that vetoing a code modification should be accompanied with a technical justification, and I have certain doubts that the above arguments qualify as such: https://www.apache.org/foundation/voting.html [[[ To prevent vetoes from being used capriciously, the voter must provide with the veto a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, etc. ). A veto without a justification is invalid and has no weight. ]]] (I'm not saying that the above rules have to be used in this particular case and that a veto is invalid, but still thought it’s worth mentioning.) Anyway, I'll stop working on the branch, because a veto has been casted. Regards, Evgeny Kotkov
