Jacek Materna wrote on Mon, May 08, 2017 at 10:46:39 +0200:
> 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.
>
> 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 [1], but it's
incomplete: it doesn't cover the dump/load issue. (Hopefully we'll
backport that issue's fix to 1.9.6.)
[1] https://mail-archives.apache.org/mod_mbox/subversion-dev/201702.mbox/%3C20170224213628.GA21715@fujitsu.shahaf.local2%3E
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
> Google?
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
(https://svn.apache.org/repos/asf/subversion/site/publish/faq.en.html),
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
workarounds.
WDYT?
> Prevention:
>
> 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:
> https://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/reject-known-sha1-collisions.sh
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
Windows".
> <<<<<<<<
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
to.)
Thanks!
Daniel
Received on 2017-05-09 14:12:08 CEST