Hi,
On Tue, May 9, 2017 at 2:12 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> 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.
>
Apologize for the ambiguity. I had the representation sharing feature
in-mind (fsfs.conf).
Ideally we know we want to fix it so that it recognizes this scenario as
two different files and does not try to share the content. The only cost to
disabling this feature by default is that you will not benefit from
the disk space savings
it provides. You can disable this feature at any time (prior to the problem
happening). Disabling the feature has no impact on the existing data in
the repository that is already using it. Only future commits will be impacted
in that they will not bother looking for the space savings. Repo's
prior to 1.6,
non-updated are do not care.
>> 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.
OK. Let's see what they put out first. Mark over at CN wrote a great verbose
starting point at
http://blogs.collab.net/subversion/subversion-sha1-collision-problem-statement-prevention-remediation-options#.WRG2JLyGM6g
>
>> >>>>>>>>>>>>>>
>> 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.
Fair.
>
>> 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?
Great. Concise. Follows precedent set.
>
>> 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".
Yes agreed - tells you something about active Windows subversion runtimes.
>
>> <<<<<<<<
>
> 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!
Great I will work on revisions.
>
> Daniel
--
Jacek Materna
CTO
Assembla
210-410-7661
Received on 2017-05-09 14:39:59 CEST