Paul Hammant wrote on Wed, 15 May 2019 13:03 +00:00:
> Problem I'm trying to solve: In an audit situation where prior commits
> were to be analyzed the owner of the repo that was motivated enough
> could tell the auditor that black was while in respect of a certain
> historical commit. Assuming the auditor had prior SHA1s (in lieu of a
> full Merkle tree), for the resources at a historical revision under
> audit.
Agreed: sha1 is not suitable for that auditor's use-case. So what?
Nothing requires the auditor to use the same checksum algorithm that
Subversion uses internally. The auditor should use a stronger hash
algorithm, even if 'svn info' doesn't provide it cheaply.
If you'd like to argue that we should provide blake2 checksums cheaply
(like 'svn info' provides the md5/sha1), that'd be one thing, but I
think you're arguing that we should migrate off sha1 as the primary key
of rep-cache and pristine stores, and I don't see a reason to do that.
Ultimately, in Subversion, if you can change a fulltext, you can also
change the metadata that records the checksum of that fulltext. That's
true both in the client and in the server. Therefore, even if we
replaced sha1 with crc32 throughout the code, all that would happen is
that that commits failing with "Server rejected the file because it
collides with some other file"[1] would become *way* more common; there
wouldn't be an attack vector.
What am I missing?
Cheers,
Daniel
[1] Assuming the committer used 'svnmucc put', since otherwise 'svn add'
might fail first with a similar error.
> Granted PDF payloads (& other large encoded-stream binaries like
> movies) are susceptible for such retroactive fakery, whereas
> CR-delimited text files with plausible content are not retroactively
> fake-able without that being clear to the eye: "Hey, that's not a C
> source file".
>
> Feel free to ignore - this can wait a number of years.
>
Received on 2019-05-15 15:27:16 CEST