doc hash-function-transition: minor & major clarifications
cover doc hash-function-transition: minor & major clarifications
Having read through the hash-function-transition.txt again, a couple of things jumped out at me:
Ævar Arnfjörð Bjarmason (2):
doc hash-function-transition: clarify how older gits die on NewHash
We weren't accurately describing how "git status" would die on NewHash repos on new versions.
doc hash-function-transition: clarify what SHAttered means
I don't think we had a good summary of how SHA-1 vulnerabilities overlap with concerns Git has, now that we've moved to the hardened SHA-1.
I may very well have gotten this new summary subtly wrong though. So please review.
.../technical/hash-function-transition.txt | 40 +++++++++++++++---- 1 file changed, 32 insertions(+), 8 deletions(-)
Signature · 1 line
2.16.2.804.g6dcf76e118
PATCH 1/2 doc hash-function-transition: clarify how older gits die on NewHash
Change the "Repository format extension" to accurately describe what happens with different versions of Git when they encounter NewHash repositories, instead of only saying what happens with versions v2.7.0 and later.
See ab9cb76f66 ("Repository format version check.", 2005-11-25) and 00a09d57eb ("introduce "extensions" form of core.repositoryformatversion", 2015-06-23) for the relevant changes to the setup code where these variables are checked.
--- Documentation/technical/hash-function-transition.txt | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
Documentation/technical/hash-function-transition.txt +8 -3
@@ -116,10 +116,15 @@ Documentation/technical/repository-version.txt) with extensions objectFormat = newhash compatObjectFormat = sha1 -Specifying a repository format extension ensures that versions of Git -not aware of NewHash do not try to operate on these repositories, -instead producing an error message: +The combination of setting `core.repositoryFormatVersion=1` and +populating `extensions.*` ensures that all versions of Git later than +`v0.99.9l` will die instead of trying to operate on the NewHash +repository, instead producing an error message. + # Between v0.99.9l and v2.7.0 + $ git status + fatal: Expected git repo version <= 0, found 1 + # After v2.7.0 $ git status fatal: unknown repository extensions found: objectformat
Signature · 1 line
2.16.2.804.g6dcf76e118
PATCH 2/2 doc hash-function-transition: clarify what SHAttered means
In reply to Ævar Arnfjörð BjarmasonAttempt to clarify what the SHAttered attack means in practice for Git. The previous version of the text made no mention whatsoever of Git already having a mitigation for this specific attack, which the SHAttered researchers claim will detect cryptanalytic collision attacks.
I may have gotten some of the nuances wrong, but as far as I know this new text accurately summarizes the current situation with SHA-1 in git. I.e. git doesn't really use SHA-1 anymore, it uses Hardened-SHA-1 (they just so happen to produce the same outputs 99.99999999999...% of the time).
Thus the previous text was incorrect in asserting that:
[...]As a result [of SHAttered], SHA-1 cannot be considered cryptographically secure any more[...]
That's not the case. We have a mitigation against SHAttered, *however* we consider it prudent to move to work towards a NewHash should future vulnerabilities in either SHA-1 or Hardened-SHA-1 emerge.
--- .../technical/hash-function-transition.txt | 29 +++++++++++++++---- 1 file changed, 24 insertions(+), 5 deletions(-)
Documentation/technical/hash-function-transition.txt +24 -5
@@ -28,11 +28,30 @@ advantages: address stored content. Over time some flaws in SHA-1 have been discovered by security -researchers. https://shattered.io demonstrated a practical SHA-1 hash -collision. As a result, SHA-1 cannot be considered cryptographically -secure any more. This impacts the communication of hash values because -we cannot trust that a given hash value represents the known good -version of content that the speaker intended. +researchers. On 23 February 2017 the SHAttered attack +(https://shattered.io) demonstrated a practical SHA-1 hash collision. + +Git v2.13.0 and later subsequently moved to a hardened SHA-1 +implementation by default, which isn't vulnerable to the SHAttered +attack. + +Thus Git has in effect already migrated to a new hash that isn't SHA-1 +and doesn't share its vulnerabilities, its new hash function just +happens to produce exactly the same output for all known inputs, +except two PDFs published by the SHAttered researchers, and the new +implementation (written by those researchers) claims to detect future +cryptanalytic collision attacks. + +Regardless, it's considered prudent to move past any variant of SHA-1 +to a new hash. There's no guarantee that future attacks on SHA-1 won't +be published in the future, and those attacks may not have viable +mitigations. + +If SHA-1 and its variants were to be truly broken Git's hash function +could not be considered cryptographically secure any more. This would +impact the communication of hash values because we could not trust +that a given hash value represented the known good version of content +that the speaker intended. SHA-1 still possesses the other properties such as fast object lookup and safe error checking, but other hash functions are equally suitable
Signature · 1 line
2.16.2.804.g6dcf76e118
Re: [PATCH 2/2] doc hash-function-transition: clarify what SHAttered means
Quoted 21 lines · Ævar Arnfjörð Bjarmason
Attempt to clarify what the SHAttered attack means in practice for Git. The previous version of the text made no mention whatsoever of Git already having a mitigation for this specific attack, which the SHAttered researchers claim will detect cryptanalytic collision attacks.
[...]Signed-off-by Ævar Arnfjörð Bjarmason <[email protected]>---
Documentation/technical/hash-function-transition.txt +10
-0@@ -28,11 +28,30 @@ advantages: Over time some flaws in SHA-1 have been discovered by security +researchers. On 23 February 2017 the SHAttered attack +(https://shattered.io) demonstrated a practical SHA-1 hash collision. + +Git v2.13.0 and later subsequently moved to a hardened SHA-1 +implementation by default, which isn't vulnerable to the SHAttered +attack. + +Thus Git has in effect already migrated to a new hash that isn't SHA-1 +and doesn't share its vulnerabilities, its new hash function just +happens to produce exactly the same output for all known inputs,
Documentation/technical/hash-function-transition.txt advantages: · line 48
Quoted 10 lines
Documentation/technical/hash-function-transition.txt +10
-0+except two PDFs published by the SHAttered researchers, and the new +implementation (written by those researchers) claims to detect future +cryptanalytic collision attacks. + +Regardless, it's considered prudent to move past any variant of SHA-1 +to a new hash. There's no guarantee that future attacks on SHA-1 won't +be published in the future, and those attacks may not have viable +mitigations. + +If SHA-1 and its variants were to be truly broken Git's hash function
s/broken/&,/
Quoted 4 lines
Documentation/technical/hash-function-transition.txt +4
-0+could not be considered cryptographically secure any more. This would +impact the communication of hash values because we could not trust +that a given hash value represented the known good version of content +that the speaker intended.
Quoted 15 lines · Ævar Arnfjörð Bjarmason
Having read through the hash-function-transition.txt again, a couple of things jumped out at me:
Ævar Arnfjörð Bjarmason (2):
doc hash-function-transition: clarify how older gits die on NewHashWe weren't accurately describing how "git status" would die on NewHash repos on new versions.
doc hash-function-transition: clarify what SHAttered means
I don't think we had a good summary of how SHA-1 vulnerabilities overlap with concerns Git has, now that we've moved to the hardened SHA-1.
Quoted 5 lines
I may very well have gotten this new summary subtly wrong though. So please review.
.../technical/hash-function-transition.txt | 40 +++++++++++++++---- 1 file changed, 32 insertions(+), 8 deletions(-)
Both patches look good to me.
Stefan