[PATCH] 1.10 Release notes and FAQ around SHA-1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH] 1.10 Release notes and FAQ around SHA-1

Jacek Materna
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.

2) Consider patching 1.10 with de-duplication off by default ?

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.

4) I am sure there are a number of other items this group can append to this dialog from previous discussions on the topic.

>>>>>>>>>>>>>>
General Questions:
 - How do I protect my repository against the SHA-1 vulnerability found by Google?


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.


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

<<<<<<<<

Best.
--

Jacek Materna
CTO

Assembla
210-410-7661
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] 1.10 Release notes and FAQ around SHA-1

Andreas Stieger
Hi,

On 08/05/17 10:46, Jacek Materna wrote:

>
> 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
>

I am not sure if this is suitable for a general audience, but I made
another hook that uses counter-cryptanalysis. It needs
https://github.com/cr-marcstevens/sha1collisiondetection/commit/5ee29e5e3e57015800f2eb6ced4cd28dd639e6dd


https://svn.apache.org/viewvc?view=revision&revision=1794454
https://svn.apache.org/viewvc/subversion/trunk/tools/hook-scripts/reject-detected-sha1-collisions.sh?view=markup&pathrev=1794454
https://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/reject-detected-sha1-collisions.sh

Have fun,
Andreas


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] 1.10 Release notes and FAQ around SHA-1

Daniel Shahaf-2
In reply to this post by Jacek Materna
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@....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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] 1.10 Release notes and FAQ around SHA-1

Jacek Materna
Hi,

On Tue, May 9, 2017 at 2:12 PM, Daniel Shahaf <[hidden email]> 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@....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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] 1.10 Release notes and FAQ around SHA-1

Daniel Shahaf-2
Jacek Materna wrote on Tue, May 09, 2017 at 14:39:51 +0200:

> On Tue, May 9, 2017 at 2:12 PM, Daniel Shahaf <[hidden email]> 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.

Current trunk behaves this way since r1785734/r1785754.  Moreover, given
the status of the "[PATCH] reject SHA1 collisions" thread, it seems
likely that 1.10.0 will refuse to admit collisions into the repository
using a FSFS-level check that's active whenever rep-sharing is.
I assume these changes address the concern underlying your point #2?

Looking forward to the revised patch.

Cheers,

Daniel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] 1.10 Release notes and FAQ around SHA-1

Stefan Sperling
In reply to this post by Jacek Materna
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] 1.10 Release notes and FAQ around SHA-1

Jacek Materna
Looks great Stefan - will review and work on the FAQ patch this week.

On Tue, May 9, 2017 at 8:43 PM, Stefan Sperling <[hidden email]> 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.



--

Jacek Materna
CTO

Assembla
210-410-7661
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] 1.10 Release notes and FAQ around SHA-1

Jacek Materna
In reply to this post by Daniel Shahaf-2
Correct. #2 is moot given the rejection strategy moving forward.

On Tue, May 9, 2017 at 6:12 PM, Daniel Shahaf <[hidden email]> wrote:
Jacek Materna wrote on Tue, May 09, 2017 at 14:39:51 +0200:
> On Tue, May 9, 2017 at 2:12 PM, Daniel Shahaf <[hidden email]> 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.

Current trunk behaves this way since r1785734/r1785754.  Moreover, given
the status of the "[PATCH] reject SHA1 collisions" thread, it seems
likely that 1.10.0 will refuse to admit collisions into the repository
using a FSFS-level check that's active whenever rep-sharing is.
I assume these changes address the concern underlying your point #2?

Looking forward to the revised patch.

Cheers,

Daniel



--

Jacek Materna
CTO

Assembla
210-410-7661
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] 1.10 Release notes and FAQ around SHA-1

Jacek Materna
For review.

best.
-j

On Wed, May 10, 2017 at 10:52 AM, Jacek Materna <[hidden email]> wrote:

> Correct. #2 is moot given the rejection strategy moving forward.
>
> On Tue, May 9, 2017 at 6:12 PM, Daniel Shahaf <[hidden email]>
> wrote:
>>
>> Jacek Materna wrote on Tue, May 09, 2017 at 14:39:51 +0200:
>> > On Tue, May 9, 2017 at 2:12 PM, Daniel Shahaf <[hidden email]>
>> > 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.
>>
>> Current trunk behaves this way since r1785734/r1785754.  Moreover, given
>> the status of the "[PATCH] reject SHA1 collisions" thread, it seems
>> likely that 1.10.0 will refuse to admit collisions into the repository
>> using a FSFS-level check that's active whenever rep-sharing is.
>> I assume these changes address the concern underlying your point #2?
>>
>> Looking forward to the revised patch.
>>
>> Cheers,
>>
>> Daniel
>
>
>
>
> --
>
> Jacek Materna
> CTO
>
> Assembla
> 210-410-7661


--

Jacek Materna
CTO

Assembla
210-410-7661

faq.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] 1.10 Release notes and FAQ around SHA-1

Daniel Shahaf-2
[devs: see penultimate paragraph (grep for "Thoughts")]

Jacek Materna wrote on Thu, May 11, 2017 at 14:56:03 +0200:
> For review.

Thanks for the patch.  I'll review the form first, then the content.

Form:

1) Please use unified diff format, as generated by 'svn diff' or 'diff -u'.
What you posted was a reversed non-unified diff.

2) Please use a text/* MIME type.  Naming the attachment with a .txt
extension usually does that.  (It is easier to review patches that are
correctly MIME'd.)

3) One </a> closing tag was missing its slash.

4) Wrap the source to 80 columns.  (I like breaking source lines at
fullstops, but that's my personal preference, not a house style.)

Content: (see inline)

> <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">&para;</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 it's key assumptions in processing content is that SHA-1 is unique for all objects.</p>

The word "its" is misspelled, but more importantly, its referent is
unclear.  I assume it means "Subversion's"?

> Subversion has two main areas of vulnerability.
> <br/>
> <ul>
> <li>The FS layer (repository) uses SHA-1.</li>
> <li>The Working Copy/RA layers use SHA-1.</li>
> </ul>

In user documentation I believe we say "FS backend" rather than "FS
layer".

> <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>.

This may sound like nitpicking, but trunk is unstable code and not
covered by a release's legal umbrella.  I think it would be better to
link to branches/1.10.x once it's created.

> As an aside, we welcome Windows developers to submit a pre-commit
> script for the Windows platform to the <a
> href="mailto:[hidden email]">Developer List<a>.

Another option here is to link to the relevant section of HACKING, see
https://subversion.apache.org/patches.  I don't have a preference one
way or the other.

Tangent: Speaking of that section of HACKING, I haven't read it in
a year or three.  Perhaps it's time we reviewed it and ensured it was as
unscary and easy to follow as possible, to make it easier for people to
get involved.

> </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 remove the content from you repository and upgrade to 1.9.6 to prevent future insertion.</p>

I don't think we recommend to *remove* the content outright but to gzip
it or otherwise transform it.

> </div>

The last few paragraphs of the patch basically summarize sha1-advisory.txt;
some of the text is from there too.  I'm not sure how to best arrange
the information between the FAQ and the advisory (and, for that matter,
notes/api-errata/ if we choose to use it).  On the one hand there's DRY,
on the other hand, there's room for summaries.  Thoughts?

Thanks for the patch, Jacek.  I like the content; we just need to decide
where it should live :)

Daniel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] 1.10 Release notes and FAQ around SHA-1

Stefan Fuhrmann-3
In reply to this post by Stefan Sperling
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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] 1.10 Release notes and FAQ around SHA-1

Jacek Materna
On Sun, May 14, 2017 at 1:59 PM, Stefan Fuhrmann
<[hidden email]> 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.txt (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] 1.10 Release notes and FAQ around SHA-1

Stefan Fuhrmann
On 16.05.2017 15:10, Jacek Materna wrote:

> On Sun, May 14, 2017 at 1:59 PM, Stefan Fuhrmann
> <[hidden email]> 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
> ]]]
Thanks for the patch!
Committed as r1795354 with a few minor tweaks.

Although the mentioned 1.9.6 does not exist, yet,
I think the hook script solution is valid and useful
information to have in the FAQ. 1.9.6 will follow
soon, I hope.

Maybe, we should add a link to the advisory into
the FAQ.

-- Stefan^2.
Loading...