On Sun, May 14, 2017 at 1:59 PM, Stefan Fuhrmann <stefanfuhrm...@alice-dsl.de> 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">