On Mon, Jun 03, 2024 at 09:36:59AM -0700, Junio C Hamano wrote: > Patrick Steinhardt <ps@xxxxxx> writes: > > > 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@xxxxxx> > > --- > > Documentation/BreakingChanges.txt | 24 ++++++++++++++++++++++++ > > 1 file changed, 24 insertions(+) > > > > diff --git a/Documentation/BreakingChanges.txt b/Documentation/BreakingChanges.txt > > index ddce7cc301..904857a636 100644 > > --- a/Documentation/BreakingChanges.txt > > +++ b/Documentation/BreakingChanges.txt > > @@ -61,6 +61,30 @@ 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@xxxxxxxxxxx>, > > +<20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>, > > +<CA+EOSBncr=4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@xxxxxxxxxxxxxx>. > > A few things we should probably list are: > > - Even if you can locally use SHA-256 in your project and > push/fetch the history around, public forges may not be ready. > > - The strategy to migrate existing SHA-1 project to SHA-256 without > going through a flag day change has been designed but not > implemented or deployed. > > - This is only about the change of the default; we currently have > no plan to drop support for SHA-1 repositories. > > IMHO, we would want each and every item in this document to mention > the risk factors that may prevent us from going forward even if we > wanted to, and the first item above is an example. > > Thanks. I agree that explicitly mentioning (1) and (3) is sensible. Is the second one important though given that this is about the default when creating _new_ repositories? I don't think interop code is a requirement to make "sha256" the default, is it? Patrick
Attachment:
signature.asc
Description: PGP signature
