>Mit Git 3.0 wird SHA-256 zum neuen Standard-Hash-Algorithmus für Repos und das wird ein unvorstellbar kostspieliger, letztendlich wertloser und vermeidbarer globaler Albtraum werden.
>Bei bestehenden Projekten, bei denen eine Umstellung von SHA-1 auf SHA-256 beschlossen wird, muss jedes Objekt im Projekt in das neue Format konvertiert werden, wodurch alle bestehenden Signaturen ungültig werden.
>Außerdem müssen alle, die an diesem Projekt arbeiten oder es nutzen, gleichzeitig umstellen, um Probleme mit geteilten Heads zu vermeiden.
>Oder man richtet erneut einen Mirror ein und leitet den Schreibzugriff von einem auf den anderen um.
>Das löst jedoch immer noch nicht das Problem des Objekt-Austauschs für andere Mirrors, die nicht über die 256-Version verfügen.
>Wenn man das Projekt jedoch auf GitHub (oder einen anderen Host) hochladen möchtest, muss man bei der Erstellung des Repositorys auf dem Server angeben, dass es sich um ein SHA-256-Projekt handelt.
>Jedes Projekt wird nun in dem einen oder dem anderen Bereich gespeichert, und eine Vermischung ist nicht möglich.
>Bei der SHA-1-Frist des NIST bis 2030 geht es darum, SHA-1 „zur Anwendung kryptografischer Schutzmaßnahmen“ zu verwenden, nicht darum, dass SHA-1 irgendwo in Ihrem Stack vorhanden ist.
>Wenn jede Signatur auch einen SHA-256-Inhalts-Hash abdeckt, dann schützt SHA-1 nichts mehr.
>Es ist lediglich ein inhaltsadressierter Schlüssel. Systeme im FIPS-Modus handhaben dies bereits:
>OpenSSL 3 ermöglicht es einer Anwendung, eine Nicht-FIPS-Implementierung eines Hash-Algorithmus anzufordern, den sie nicht für Sicherheitszwecke verwendet
https://blog.gitbutler.com/git-3-sha-256