[PATCH] Tweak the SHA-1 FAQ entry

Hi all,

I made an attempt to tweak the SHA-1 FAQ entry (which is available at
https://subversion.apache.org/faq#shattered-sha1) to make it a bit more
user-friendly.

Please see the attached patch. What do you think about making a change
like this?

For convenience, here is the final result as plain text:

[[[
How is Subversion affected by SHA-1 hash collisions?

Publication of the first known SHA-1 collision by Google and CWI unveiled a
couple of related issues in the Subversion's use of SHA-1. The Subversion's
core does not rely on SHA-1 for content indexing, but it was being used for
such purposes in the following supplementary features:

- repository data deduplication feature, and
- content deduplication feature in the working copy.

Speaking of the repository data deduplication feature, this can result in
inability to access files with colliding SHA-1 values or cause data loss for
such files. To prevent different content with identical SHA-1 from being
stored in a repository, upgrade to 1.9.6 or 1.8.18 which, by default,
prevent storing data with such collisions. See our SHA-1 advisory for
details.

Until the upgrade to these new releases is available, Unix-based servers can
use the pre-commit hook found here. As an aside, we welcome Windows developers
to submit a pre-commit script for the Windows platform. More information on
submission can be found here.

The working copy uses SHA-1 for deduplication of the stored content, and for
performance reasons a client will avoid fetching content with the same SHA-1
checksum. The workaround for this issue is 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.

Storing content with SHA-1 collisions it not a supported use case. If you
have content with colliding SHA-1 hash values, we suggest you transform it
via gzip before committing it to avoid the collision altogether. Moreover,
an upgrade to 1.9.6 to prevent future insertion of duplicates is highly
recommended.
]]]

Regards,
Evgeny Kotkov