Jacek Materna wrote on Mon, May 08, 2017 at 10:46:39 +0200:
> 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.
> 1) We should bias towards pro-active mitigation of this issue in docs/code
> as we know a real solution will likely NOT come with 1.10 after all.
Agreed: a solution in code would be preferable, but whichever cases are
not working as we want them to, should be documented.
> 2) Consider patching 1.10 with de-duplication off by default ?
What's the rationale behind this? (honest question)
I can see that this would, for one, allow sha1 collisions to be
committed over RA, but I'm not sure what benefit you have in mind.
> 3) Remediation of the issue (if affected) should be a different topic? -
> how to get out of the weeds guide. Published by the group - authoritative,
> trusted, final. A number of providers of SVN hosting have done their own
> workarounds and written their own KB's on the topic - I think having a
> master guide is important.
Agreed. Moreover, it'd be nice to draw on the knowledge accumulated in
our downstreams. I tried to provide such a guide in , but it's
incomplete: it doesn't cover the dump/load issue. (Hopefully we'll
backport that issue's fix to 1.9.6.)
Incidentally, that email is from late February, so the "90 days to
publishing the exploit code" will be over soon.
> General Questions:
> - How do I protect my repository against the SHA-1 vulnerability found by
I see this is a patch for the FAQ. For future reference, we prefer
patches to be formatted in unidiff against the site's HTML source
however, I agree it's easier to first iterate on the wording and only
later add the HTML markup.
I suggest to say "shattered" somewhere in the question's title, to
unambiguously identify the attack.
> Subversion's use of SHA-1 in how it processes content is subject to hashing
> collisions as identified by Google (https://shattered.io/). Preventing
> suspect object commits is the simplest and best way today to protect your
> repository. Disabling repository sharing is not enough to solve the issue
> alone as Subversion also uses SHA-1 to de-duplicate retransmission of
> content to clients for a pristine working copy.
This paragraph tries to say two things:
1. The FS layer (repository) uses sha1. Workaround: use this hook
script. (Or upgrade to 1.10.0 / 1.9.TBD ?)
2. The WC/RA layers use sha1. Workaround: none yet.
I would suggest to make this division explicit. E.g., we could say:
"Subversion uses sha1 in X and Y.
X uses sha1 for ... The new failure modes / attacks are ... The
workaround / fix is...
Y uses sha1 for ... The new failure modes / attacks are ... The
workaround / fix is...
Basically, each paragraph would follow the same structure as our
advisories: design description, problem description, fixes and
> Install a pre-commit hook that will reject new instances against known
> collisions. While this will not guarantee protection from new collisions,
> we will keep the hook up-to date as new collisions are publicly released.
> The hook can be found here:
The FAQ entry should also cater to Windows admins, if nothing else than
by saying "We'd welcome patches adding an equivalent hook script for
Looks good. This should eventually be linked to from the (1.9 and/or
1.10) release notes as well, I imagine. (The 1.10 release notes are
drafted in /docs/release-notes/1.10.html, but not yet publicly linked
Received on 2017-05-09 14:12:08 CEST