subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacek Materna <>
Subject Re: [PATCH] Tweak the SHA-1 FAQ entry
Date Fri, 07 Jul 2017 15:11:44 GMT
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
<> wrote:
> Hi all,
> I made an attempt to tweak the SHA-1 FAQ entry (which is available at
> 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

+1 210 410 7661
+48 578 296 708

View raw message