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.kotkov_at_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
Received on 2017-07-07 17:12:33 CEST