Shouldn't vulnerability / shattered remain a keyword? I believe it was a comment in the patch I submitted - just wondering about google-ness of it... shattered has a lot of google juice.
collision vs. 'shattered / vulnerability' Otherwise more complete verbiage is always good. On Fri, Jul 7, 2017 at 4:46 PM, Evgeny Kotkov <evgeny.kot...@visualsvn.com> wrote: > > 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 > 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 -- Jacek Materna CTO Assembla +1 210 410 7661 +48 578 296 708
