Re: [PATCH v5 2/4] BreakingChanges: document upcoming change from "sha1" to "sha256"

[Patrick Steinhardt <ps@pks.im>]

[-- Attachment #1: Type: text/plain, Size: 4238 bytes --]

On Mon, Jun 03, 2024 at 09:36:59AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> 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@pks.im>
> > ---
> >  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@zombino.com>,
> > +<20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>,
> > +<CA+EOSBncr=4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com>.
> 
> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]