On Sun, May 14, 2017 at 1:59 PM, Stefan Fuhrmann
<[email protected]> wrote:
> On 09.05.2017 20:43, Stefan Sperling wrote:
>>
>> On Mon, May 08, 2017 at 10:46:39AM +0200, Jacek Materna wrote:
>>>
>>> Team,
>>>
>>> I wanted to start a discussion around the FAQ (and 1.10 rls. notes) as it
>>> pertains to the SHA-1 issue affecting all versions of SVN RE: "Continue
>>> the
>>> 1.10 alphas?" thread.
>>
>> I have added a small advisory-style writeup we could mail out along
>> with a 1.9.6 release announcement: http://svn.apache.org/r1794624
>> Does this look OK?
>>
>> Of course, the FAQ and such could still be updated.
>>
> Looks good!
>
> The only thing I'm not sure about is whether to
> stress the fact that the user will also lose data.
> It's there, implicitly, but the wording feels a bit
> too focussed on the "errors and inconvenience"
> side of things.
>
> -- Stefan^2.
>
>
I have not changed the reference to the trunk version of the hook
script as I have not seen a stable "release" branch/tag version which
has it in place yet. I assume this will come after release.
[[[
Add to website FAQ around SHA-1 vulnerability
]]]
--- faq.html 2017-03-16 17:18:18.000000000 +0100
+++ faq.new.html 2017-05-16 14:47:08.000000000 +0200
@@ -61,6 +61,8 @@
list?</a></li>
<li><a href="#dst-2007">How is Subversion affected by changes
in Daylight Savings Time (DST)?</a></li>
+<li><a href="#shatterd-sha1">How do I protect my repository from the SHA-1
+ Shattered vulnerability?</a></li>
</ul>
<h4>How-to:</h4>
@@ -743,6 +745,47 @@
</div>
+<div class="h3" id="shatterd-sha1">
+<h3>How do I protect my repository from the SHA-1 Shattered vulnerability?
+ <a class="sectionlink" href="#shatterd-sha1"
+ title="Link to this section">¶</a>
+</h3>
+
+<p>Subversion's use of SHA-1 in how it processes content is subject to hashing
+collisions as identified by <a href="https://shattered.io/";>Google</a>). One of
+Subversions's key assumptions in processing content is that SHA-1 is unique
for
+all objects.</p>
+Subversion has two main areas of vulnerability.
+<br/>
+<ul>
+<li>The FS backend (repository) uses SHA-1.</li>
+<li>The Working Copy/RA layers use SHA-1.</li>
+</ul>
+<p>
+The FS layer uses SHA-1 when identifying objects to store in the repository.
To
+prevent non duplicate content from being stored that has identical SHA-1,
+upgrade to 1.9.6 (where would prevent storage of duplicates) or install the
+pre-commit hook found <a
href="https://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/reject-known-sha1-collisions.sh";>
+here</a>. As an aside, we welcome Windows developers to submit a pre-commit
+script for the Windows platform. More information on submission can be found
<a
href="https://subversion.apache.org/docs/community-guide/general.html#patches";>
+here</a>.
+</p>
+<p>
+The working copy/RA layer uses SHA-1 for de-duplication of content stored in
+the working copy, and for performance reasons clients using the HTTP protocol
+will avoid fetching content with a SHA-1 checksum which has been fetched
+previously. There is no known workaround for this vector except 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.
+</p>
+<p>
+Storing content with SHA1 collisions it not a supported use case. If you have
+repositories with colliding SHA-1 content we suggest you transform it via gzip
+before storage to avoid the collision altogether. Moreover an upgrade to 1.9.6
+to prevent future insertion duplicates is highly recommended.</p>
+
+</div>
+
</div>
<div class="h2" id="how-to">
