You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Evgeny Kotkov <ev...@visualsvn.com> on 2017/07/07 14:46:25 UTC
[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
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
Re: [PATCH] Tweak the SHA-1 FAQ entry
Posted by Evgeny Kotkov <ev...@visualsvn.com>.
Bert Huijben <be...@qqmail.nl> writes:
> Except for s/ it / is / on this line, +1... Looks very good!
Jacek Materna <ja...@assembla.com> writes:
> Fair enough!
>
> Rest looks great.
I fixed the typo and committed the patch in https://svn.apache.org/r1801202
Regards,
Evgeny Kotkov
Re: [PATCH] Tweak the SHA-1 FAQ entry
Posted by Jacek Materna <ja...@assembla.com>.
Fair enough!
Rest looks great.
--
Jacek Materna
Assembla
CTO
+1 210 410 7661
+48 578 296 708
Sent from my Mobile Device
> On Jul 7, 2017, at 5:47 PM, Evgeny Kotkov <ev...@visualsvn.com> wrote:
>
> Jacek Materna <ja...@assembla.com> writes:
>
>> 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.
>
> I was thinking about turning this FAQ entry into a more or less generic
> statement about Subversion and SHA-1 collisions, rather than making it
> centered around one particular kind of collision (https://shattered.io/).
>
>
> Regards,
> Evgeny Kotkov
Re: [PATCH] Tweak the SHA-1 FAQ entry
Posted by Evgeny Kotkov <ev...@visualsvn.com>.
Jacek Materna <ja...@assembla.com> writes:
> 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.
I was thinking about turning this FAQ entry into a more or less generic
statement about Subversion and SHA-1 collisions, rather than making it
centered around one particular kind of collision (https://shattered.io/).
Regards,
Evgeny Kotkov
Re: [PATCH] Tweak the SHA-1 FAQ entry
Posted by Jacek Materna <ja...@assembla.com>.
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
<ev...@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
RE: [PATCH] Tweak the SHA-1 FAQ entry
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Evgeny Kotkov [mailto:evgeny.kotkov@visualsvn.com]
> Sent: vrijdag 7 juli 2017 16:46
> To: Subversion Development <de...@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