[PATCH 0/2] doc hash-function-transition: minor & major clarifications

[PATCH 0/2] doc hash-function-transition: minor & major clarifications

[Æ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 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(-)

-- 
2.16.2.804.g6dcf76e118

[PATCH 1/2] doc hash-function-transition: clarify how older gits die on NewHash

[Ævar Arnfjörð Bjarmason]

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.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 Documentation/technical/hash-function-transition.txt | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt
index 417ba491d0..34396f13ec 100644
--- a/Documentation/technical/hash-function-transition.txt
+++ b/Documentation/technical/hash-function-transition.txt
@@ -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
-- 
2.16.2.804.g6dcf76e118

[PATCH 2/2] doc hash-function-transition: clarify what SHAttered means

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

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.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 .../technical/hash-function-transition.txt    | 29 +++++++++++++++----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt
index 34396f13ec..34b8b83a34 100644
--- a/Documentation/technical/hash-function-transition.txt
+++ b/Documentation/technical/hash-function-transition.txt
@@ -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
-- 
2.16.2.804.g6dcf76e118

Re: [PATCH 0/2] doc hash-function-transition: minor & major clarifications

[Stefan Beller]

On Mon, Mar 26, 2018 at 11:27 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com>
wrote:

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

Both patches look good to me.

Stefan

Re: [PATCH 2/2] doc hash-function-transition: clarify what SHAttered means

[Eric Sunshine]

On Mon, Mar 26, 2018 at 2:27 PM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> 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 <avarab@gmail.com>
> ---
> diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt
> @@ -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,
> +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/&,/

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