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
