diff mbox series

[v4,2/4] BreakingChanges: document upcoming change from "sha1" to "sha256"

Message ID 7c84b2f957595a3d8bc6d28970a009339c5fbf5c.1717141598.git.ps@pks.im (mailing list archive)
State Superseded
Headers show
Series docs: document upcoming breaking changes | expand

Commit Message

Patrick Steinhardt May 31, 2024, 7:56 a.m. UTC
Starting with 8e42eb0e9a (doc: sha256 is no longer experimental,
2023-07-31), the "sha256" object format is no longer considered to be
experimental. Furthermore, the SHA-1 hash function is actively
recommended against by for example NIST and FIPS 140-2, and attacks
against it are becoming more practical both due to new weaknesses
(SHAppening, SHAttered, Shambles) and due to the ever-increasing
computing power. It is only a matter of time before it can be considered
to be broken completely.

Let's plan for this event by being active instead of waiting for it to
happend and announce that the default object format is going to change
from "sha1" to "sha256" with Git 3.0.

All major Git implementations (libgit2, JGit, go-git) support the
"sha256" object format and are thus prepared for this change. The most
important missing piece in the puzzle is support in forges. But while
GitLab recently gained experimental support for the "sha256" object
format though, to the best of my knowledge GitHub doesn't support it
yet. Ideally, announcing this upcoming change will encourage forges to
start building that support.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Documentation/BreakingChanges.md | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

Comments

Junio C Hamano May 31, 2024, 5 p.m. UTC | #1
Patrick Steinhardt <ps@pks.im> writes:

> Let's plan for this event by being active instead of waiting for it to
> happend and announce that the default object format is going to change
> from "sha1" to "sha256" with Git 3.0.

"happened" -> "happen,"

> All major Git implementations (libgit2, JGit, go-git) support the
> "sha256" object format and are thus prepared for this change. The most
> important missing piece in the puzzle is support in forges. But while
> GitLab recently gained experimental support for the "sha256" object
> format though, to the best of my knowledge GitHub doesn't support it
> yet. Ideally, announcing this upcoming change will encourage forges to
> start building that support.

;-)  Nevertheless, we probably want some of that in the body text.

> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  Documentation/BreakingChanges.md | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>
> diff --git a/Documentation/BreakingChanges.md b/Documentation/BreakingChanges.md
> index d8a26c9bf9..1b0a357e65 100644
> --- a/Documentation/BreakingChanges.md
> +++ b/Documentation/BreakingChanges.md
> @@ -56,6 +56,33 @@ be changed to or replaced in case the alternative was implemented already.
>  
>  ### Changes
>  
> +  - The default hash function for new repositories will be changed from "sha1"
> +    to "sha256". SHA-1 has been deprecated by NIST in 2011 and is nowadays
> +    recommended against in FIPS 140-2 and similar certifications. Furthermore,
> +    there are practical attacks on SHA-1 that weaken its cryptographic properties:
> +
> +      - The SHAppening (2015). The first demonstration of a practical attack
> +        against SHA-1 with 2^57 operations.
> +
> +      - SHAttered (2017). Generation of two valid PDF files with 2^63 operations.
> +
> +      - Birthday-Near-Collision (2019). This attack allows for chosen prefix
> +        attacks with 2^68 operations.
> +
> +      - Shambles (2020). This attack allows for chosen prefix attacks with 2^63
> +        operations.
> +
> +    While we have protections in place against known attacks, it is expected
> +    that more attacks against SHA-1 will be found by future research. Paired
> +    with the ever-growing capability of hardware, it is only a matter of time
> +    before SHA-1 will be considered broken completely. We want to be prepared
> +    and will thus change the default hash algorithm to "sha256" for newly
> +    initialized repositories.
> +
> +    Cf. <2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com>,
> +        <20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>,
> +        <CA+EOSBncr=4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com>.

We probably need to at least briefly mention external constraints
here.  Even though in our ideal world, what we say here will force
others like GitHub to follow, in the real world that is not always
the case.  As this particular commit is about establishing the
pattern, expected form of each entry, how about adding convention to
have a paragraph on "foreseen risks", in addition to the "what we
plan to do", and "why we want to go there" we see above?

>  ### Removals
>  
>  ## Superseded features that will not be deprecated

Thanks.
diff mbox series

Patch

diff --git a/Documentation/BreakingChanges.md b/Documentation/BreakingChanges.md
index d8a26c9bf9..1b0a357e65 100644
--- a/Documentation/BreakingChanges.md
+++ b/Documentation/BreakingChanges.md
@@ -56,6 +56,33 @@  be changed to or replaced in case the alternative was implemented already.
 
 ### Changes
 
+  - The default hash function for new repositories will be changed from "sha1"
+    to "sha256". SHA-1 has been deprecated by NIST in 2011 and is nowadays
+    recommended against in FIPS 140-2 and similar certifications. Furthermore,
+    there are practical attacks on SHA-1 that weaken its cryptographic properties:
+
+      - The SHAppening (2015). The first demonstration of a practical attack
+        against SHA-1 with 2^57 operations.
+
+      - SHAttered (2017). Generation of two valid PDF files with 2^63 operations.
+
+      - Birthday-Near-Collision (2019). This attack allows for chosen prefix
+        attacks with 2^68 operations.
+
+      - Shambles (2020). This attack allows for chosen prefix attacks with 2^63
+        operations.
+
+    While we have protections in place against known attacks, it is expected
+    that more attacks against SHA-1 will be found by future research. Paired
+    with the ever-growing capability of hardware, it is only a matter of time
+    before SHA-1 will be considered broken completely. We want to be prepared
+    and will thus change the default hash algorithm to "sha256" for newly
+    initialized repositories.
+
+    Cf. <2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com>,
+        <20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>,
+        <CA+EOSBncr=4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com>.
+
 ### Removals
 
 ## Superseded features that will not be deprecated