svn commit: r1794707 - /subversion/trunk/notes/sha1-advisory.txt

[st...@apache.org]

Author: stsp
Date: Wed May 10 11:33:39 2017
New Revision: 1794707

URL: http://svn.apache.org/viewvc?rev=1794707&view=rev
Log:
* notes/sha1-advisory.txt: Various tweaks for more clarity.

Suggested by: danielsh

Modified:
    subversion/trunk/notes/sha1-advisory.txt

Modified: subversion/trunk/notes/sha1-advisory.txt
URL: http://svn.apache.org/viewvc/subversion/trunk/notes/sha1-advisory.txt?rev=1794707&r1=1794706&r2=1794707&view=diff
==============================================================================
--- subversion/trunk/notes/sha1-advisory.txt (original)
+++ subversion/trunk/notes/sha1-advisory.txt Wed May 10 11:33:39 2017
@@ -25,18 +25,18 @@ Details:
   different content but produce the same SHA1 checksum. This was the first
   publicly known SHA1 collision ever produced.
 
-  If both of these files are committed to a Subversion repository, Subversion
-  de-duplicates content based on the SHA1 checksum and only the content of
-  one of the files ends up being stored in the repository. However, meta data
+  If both of these files are committed to an FSFS or FSX repository, content
+  is de-duplicated based on the SHA1 checksum, and only the content of one
+  of the files ends up being stored in the repository. However, meta data
   stores the MD5 checksums of both files, and these MD5 checksums differ.
   This causes problems when Subversion eventually uses the MD5 checksum of
   the content which was not in fact stored. For example, updates and commits
-  may no longer be possible due to an apparent checksum error.
+  may fail with a checksum error. 
 
 Recommendations:
 ================
 
-  We recommend all users update to Subversion 1.9.6 which will reject any
+  We recommend all users upgrade to Subversion 1.9.6 which will reject any
   commit that would create a SHA1 collision.
 
   Note that this fix only works if the "representation-sharing" feature is
@@ -62,11 +62,11 @@ Recommendations:
   One solution is just to delete the second file. This will resolve this
   problem for normal SVN client usage, but it will not work for tools like
   svnsync or git-svn which try to replay every revision in the repository.
-  This will run into an error on the revision where the content was committed
-  and the tool will not be able to proceed.
+  The tool will run into an error on the revision where the content was
+  committed and the tool will not be able to proceed.
 
   A second solution would be to remove the problematic revision with svnadmin.
-  svnadmin dump can be used to dump the repository up to the revision that
+  'svnadmin dump' can be used to dump the repository up to the revision that
   introduced the problem. This dump file can be loaded into a new repository.
   If there were more commits after the problematic revision then dump and load
   all of these subsequent revisions as well.
@@ -74,6 +74,11 @@ Recommendations:
   Another option is to create a Subversion permission rule (authz) that blocks
   access to the one or both of the files. This will work with tools like
   svnsync and git-svn as the server will not send the colliding content.
+  For example, authz rules which block access to the files could look like:
+    [/trunk/tests/data/shattered-1.pdf]
+    * =
+    [/trunk/tests/data/shattered-2.pdf]
+    * =
 
 References:
 ===========