Gits nya hash-standard – vad det innebär
Gits föreslagna SHA-256 standard skapar en kompatibilitetsgräns för nya "repositories".
Gits föreslagna SHA-256 standard skapar en kompatibilitetsgräns för nya "repositories". Vi granskar den officiella planen, Scott Chacóns invändning och ett fungerande GitHub-förhandsundantag, täcker sedan Pi 1.0 och SvelteKit 3. Bedömning: NEEDS REVIEW.
Läs den skrivna upplagan (engelska) ↗
Vad den här videon täcker
- Varför kan två Git-"repositories" vägra att kommunicera?
- Vad ändrar Git 3 egentligen?
- Varför byta ut SHA-1 om Git upptäcker kollisioner?
- Vad visade vår lokala kompatibilitetskontroll?
- Vad överlever en krasch i Pi Durable?
Översatt transkription
Översatt från den ursprungliga engelska berättelsen. Tillgängligt ljud och undertexter styrs av YouTube.
Varför kan två Git-"repositories" vägra att kommunicera?
0:00 Man skulle kunna tro att uppgradering av Git håller dina verktyg kommunicerande. Gits planerade nya hash-standard skapar "repositories" som dagens gamla format inte kan kommunicera med. I den här videon, varför ändra? Vad går sönder? Vem är redo? Det finns redan ett fungerande undantag på GitHub. Jag visar dig vad det bevisar i slutet. Det är fredag, andra oktober, och detta är The Daily Diff.
0:18 På torsdagen kallade en GitHub-medgrundare Gits planerade förändring för ett kostsamt misstag. Pi skickade ett nytt agent-harness, och SvelteKit skickade en annan migration. Scott Chacon hjälpte till att bygga GitHub och skrev Pro Git, så detta klagomål kommer inifrån. huset. Huset säljer också Git-verktyg. Först, den faktiska planen.
Vad ändrar Git 3 egentligen?
0:35 Git 3 skulle som standard använda SHA-256 för nya "repositories", när bibliotek och hostingtjänster är redo att stödja det. Det officiella dokumentet anger inget releasedatum och håller SHA-1 stöttat. Ditt befintliga "repository" ändrar inte magiskt format när du uppgraderar "executable". Det är värt att komma ihåg innan din gruppchatt schemalägger en akut migration. Dramat är en föreslagen standard, och tidsfristen är för närvarande en tom kalender.
Varför byta ut SHA-1 om Git upptäcker kollisioner?
0:58 Varför ändra alls? Git namnger objekt genom att hasha deras innehåll. Filer matas in i träd, och commits hänvisar till träd och tidigare commits. Detta ger dig integritet genom hela historien. Ändra hash-schemat och objektnamnen ändras också, inklusive referenserna som lagras inuti andra objekt. Chacon hänvisar till Linus Torvalds, Gits skapare, och menar att tillförlitlig
1:17 distribution spelar roll. Det är en historisk position, och Linus valde SHA-1 redan år 2005. Säkerhetsfrågan har rört sig sedan dess. Forskare demonstrerade SHA-1-kollisioner år 2017, och demonstrerade senare en "chosen prefix attack" mot PGP-identitetscertifikat. Modern Git upptäcker kända kollisionsattacker med härdad SHA-1. Dess underhållare vill också ha skydd mot framtida attacker, vilket är rimligt att önska sig av signaturer.
1:41 Chacon anser att ekosystemets kostnad ger för lite säkerhet. Han föreslår att man signerar en separat stark kontrollsumma av trädinnehållet, samtidigt som dagens objektadressering behålls under. Vad går sönder? Jag skapade båda formaten lokalt och hashade samma lilla fil.
Vad visade vår lokala kompatibilitetskontroll?
1:54 Ett objektnamn har fyrtio hex-tecken, det andra har sextiofyra. Sedan försökte jag hämta mellan dem. Min installerade Git avvisade det med felaktiga algoritmer, exakt den kompatibilitetslucka som beskrivs i den nuvarande officiella manualen. Detta använde min gamla installerade Git, så det berättar för oss om dagens gräns. Att kalla det ett test av den orelaterade Git 3 skulle vara kreativ bokföring. Migrationsarbetet når in i skript som antar en hashes längd, och system som länkar till objektnamn.
2:19 Att rehasha en historik kräver en mappning mellan dessa identiteter. Gits övergångsdesign inkluderar den mappningen och signaturhantering. Implementeringsberedskap spelar roll, eftersom ett designdokument inte uppgraderar biblioteket som gömmer sig i ditt favoritutvecklingsverktyg. Det är den mänskliga kostnaden i Chacóns argument. Varje verktygsunderhållare får ytterligare ett kompatibilitetsjobb, medan användare upptäcker att deras versionskontroll nu behöver versionskontroll. Testa för närvarande din värd och dina verktyg innan du väljer det nya formatet för ett
2:44 projekt. Befintliga team kan behålla sitt nuvarande format medan ekosystemet hinner ikapp. Under tiden nådde Pi version 1.0.
Vad överlever en krasch i Pi Durable?
2:51 Det är ett "coding agent harness" från Earendil, med inbyggt MCP-stöd via Codemode och verktyg som laddas när de behövs. Teamet kallar minimalismen för poängen. Om din agentinstallation redan liknar en liten regering, att hålla verktyg borta från prompten tills de behövs låter som en administrativ reform. Den släppte också Pi Durable, ett separat experimentellt ramverk. Uppgifter sparar checkpoints så att en omstartad process kan fortsätta oavslutat arbete från beständig lagring. Den avgörande detaljen är verktygs-replay.
3:16 Ett verktyg som avbrutits av en krasch körs om endast när det förklarar det säkert. Annars får modellen veta att den avbröts. Det är en användbar gräns när ett verktyg kan spendera pengar. Jag vill att assistenten ska komma ihåg min inköpslista utan att fira en krasch genom att köpa den två gånger.
Vad migrerar SvelteKit 3 åt dig?
3:30 SvelteKit 3 lanserades också på torsdagen, flyttade konfigurationen till Vite och ersatte dollar lib med hash lib, med standard subpath-import av paket. Migrationskommandot skriver om vad det kan och lämnar en att-göra-lista för resten. Din robot kan hjälpa till, och din diff förtjänar fortfarande att läsas. Meddelandet rekryterar till och med dina robotvänner för resterna. Vi når punkten där en ramverksuppgradering skickar hemläxa och en föreslagen vikarie. Och fjärrfunktioner behöver fortfarande experimentell Async Svelte.
3:56 Ett större versionsnummer känns lugnande, men enskilda funktioner bär sina egna mognadsetiketter. Kontrollera de du faktiskt använder.
Vad bevisar GitHubs fungerande undantag?
4:03 Så vem är redo för Gits nya format? Här är undantaget. Ett offentligt GitHub-"repository" som innehåller Brian Carlsons föredrag returnerar redan ett fullständigt SHA-256 objektnamn. Jag kontrollerade den offentliga fjärrkontrollen direkt. Föredragets bilder kallar stödet en privat förhandsgranskning och säger att skapande av "repositories" är fortfarande på gång. Det finns faktisk framsteg bakom väntrummet. Det bevisar att GitHub kan hantera detta förhandsgransknings-"repository".
4:24 Det ger oss ingen garanti att vanlig projektgenerering eller alla dina integrationer är redo. Undantaget har en behörighetsgräns. Om du hellre läser detta än hör mig säga det, landar diffen i din inkorg varje morgon, gratis på thedailydiff.dev, länk nedan. Så dagens bedömning är NEEDS REVIEW.
Varför beror min bedömning på hela verktygskedjan?
4:40 Jag skulle behålla det starkare hash-alternativet och testa hela verktygskedjan innan jag ändrade standardinställningarna. Kompatibilitet är en del av att leverera säkerhetsförbättringen. Och det var diffen för idag. Jag är Niko från Axrisi. Slå samman ansvarsfullt.
Källor
- Chaconblog.gitbutler.com
- Git's official plangit-scm.com
- Current interoperabilitygit-scm.com
- Transition designgit-scm.com
- Independent collision researchsha-mbles.github.io
- GitHub preview repositorygithub.com
- Pi 1.0earendil.com
- Pi Durableearendil.com
- SvelteKit 3svelte.dev
- HN discussionnews.ycombinator.com



