> -----Original Message----- > From: Evgeny Kotkov [mailto:evgeny.kot...@visualsvn.com] > Sent: vrijdag 7 juli 2017 16:46 > To: Subversion Development <dev@subversion.apache.org> > Subject: [PATCH] Tweak the SHA-1 FAQ entry > > Hi all, > > I made an attempt to tweak the SHA-1 FAQ entry (which is available at > https://subversion.apache.org/faq#shattered-sha1) to make it a bit more > user-friendly. > > Please see the attached patch. What do you think about making a change > like this? > > For convenience, here is the final result as plain text: > > [[[ > How is Subversion affected by SHA-1 hash collisions? > > Publication of the first known SHA-1 collision by Google and CWI unveiled a > couple of related issues in the Subversion's use of SHA-1. The Subversion's > core does not rely on SHA-1 for content indexing, but it was being used for > such purposes in the following supplementary features: > > - repository data deduplication feature, and > - content deduplication feature in the working copy. > > Speaking of the repository data deduplication feature, this can result in > inability to access files with colliding SHA-1 values or cause data loss for > such files. To prevent different content with identical SHA-1 from being > stored in a repository, upgrade to 1.9.6 or 1.8.18 which, by default, > prevent storing data with such collisions. See our SHA-1 advisory for > details. > > Until the upgrade to these new releases is available, Unix-based servers can > use the pre-commit hook found here. As an aside, we welcome Windows > developers > to submit a pre-commit script for the Windows platform. More information > on > submission can be found here. > > The working copy uses SHA-1 for deduplication of the stored content, and for > performance reasons a client will avoid fetching content with the same SHA-1 > checksum. The workaround for this issue is to prevent storage of the colliding > objects in the first place, via upgrade to 1.9.6 or installation of the > aforementioned pre-commit script. > > Storing content with SHA-1 collisions it not a supported use case. If you
Except for s/ it / is / on this line, +1... Looks very good! Thanks, Bert > have content with colliding SHA-1 hash values, we suggest you transform it > via gzip before committing it to avoid the collision altogether. Moreover, > an upgrade to 1.9.6 to prevent future insertion of duplicates is highly > recommended. > ]]] > > > Regards, > Evgeny Kotkov