Gits nye standard hash – hva det betyr
Gits foreslåtte SHA-256 standard skaper en kompatibilitetsgrense for nye repositorier.
Gits foreslåtte SHA-256 standard skaper en kompatibilitetsgrense for nye repositorier. Vi sjekker den offisielle planen, Scott Chacons innvending og et fungerende GitHub forhåndsvisningsunntak, deretter dekker vi Pi 1.0 og SvelteKit 3. Dom: NEEDS REVIEW.
Les den skriftlige utgaven (engelsk) ↗
Hva denne videoen dekker
- Hvorfor kan to Git-repositorier nekte å snakke sammen?
- Hva endrer Git 3 faktisk?
- Hvorfor erstatte SHA-1 hvis Git oppdager kollisjoner?
- Hva viste vår lokale kompatibilitetssjekk?
- Hva overlever et krasj i Pi Durable?
Oversatt transkripsjon
Oversatt fra den originale engelske fortellingen. Tilgjengelig lyd og undertekster kontrolleres av YouTube.
Hvorfor kan to Git-repositorier nekte å snakke sammen?
0:00 Man skulle tro at oppgradering av Git holder verktøyene dine snakkende. Gits planlagte nye hash-standard skaper repositorier som dagens gamle format ikke kan snakke med. I denne videoen, hvorfor endre? Hva bryter? Hvem er klar? Det er allerede et fungerende unntak på GitHub. Jeg skal vise deg hva det beviser til slutt. Det er fredag, andre oktober, og dette er The Daily Diff.
0:18 På torsdag kalte en GitHub-medgrunnlegger Gits planlagte endring en kostbar feil. Pi sendte en ny agent-sele, og SvelteKit sendte en annen migrering. Scott Chacon hjalp til med å bygge GitHub og skrev Pro Git, så denne klagen kommer fra innsiden av huset. Huset selger også Git-verktøy. Først, den faktiske planen.
Hva endrer Git 3 faktisk?
0:35 Git 3 ville som standard sette nye repositorier til SHA-256, når biblioteker og hostingtjenester er klare til å støtte det. Det offisielle dokumentet gir ingen utgivelsesdato og beholder SHA-1 støttet. Ditt eksisterende repositorium endrer ikke format magisk når du oppgraderer den kjørbare filen. Det er verdt å huske før gruppechatten din planlegger en nødsmigrering. Dramaet er en foreslått standard, og fristen er for øyeblikket en tom kalender.
Hvorfor erstatte SHA-1 hvis Git oppdager kollisjoner?
0:58 Hvorfor endre i det hele tatt? Git navngir objekter ved å hashe innholdet deres. Filer mates inn i trær, og commits refererer til trær og tidligere commits. Det gir deg integritet gjennom historien. Endre hash-skjemaet og objektnavnene endres også, inkludert referansene som er lagret inne i andre objekter. Chacon refererer tilbake til Linus Torvalds, Gits skaper, og argumenterer for at pålitelig
1:17 distribusjon er viktig. Det er en historisk posisjon, og Linus valgte SHA-1 tilbake i 2005. Sikkerhetssaken har beveget seg siden den gang. Forskere demonstrerte SHA-1 kollisjoner i 2017, og demonstrerte senere et valgt prefiksangrep mot PGP-identitetssertifikater. Moderne Git oppdager kjente kollisjonsangrep med herdet SHA-1. Vedlikeholderne ønsker også beskyttelse mot fremtidige angrep, noe som er rimelig å ønske fra signaturer.
1:41 Chacon mener økosystemregningen kjøper for lite sikkerhet. Han foreslår å signere en separat sterk sjekksum av treinnhold, samtidig som dagens objektadressering beholdes under. Hva bryter? Jeg opprettet begge formatene lokalt og hashet den samme lille filen.
Hva viste vår lokale kompatibilitetssjekk?
1:54 Ett objektnavn har førti heksadesimale tegn, det andre har sekstifire. Deretter prøvde jeg å hente mellom dem. Mitt installerte Git avviste det med uoverensstemmende algoritmer, nøyaktig kompatibilitetsgapet beskrevet i den nåværende offisielle manualen. Dette brukte mitt gamle installerte Git, så det forteller oss om dagens grense. Å kalle det en test av det uutgitte Git 3 ville være kreativ regnskap. Migreringsarbeidet når inn i skript som antar en hashes lengde, og systemer som lenker til objektnavn.
2:19 Å omhashe en historie krever en kartlegging mellom disse identitetene. Gits overgangsdesign inkluderer den kartleggingen og signaturhåndteringen. Implementeringsklarhet er viktig, fordi et designdokument ikke oppgraderer biblioteket som skjuler seg i ditt favoritt utviklerverktøy. Det er den menneskelige kostnaden i Chacons argument. Hver verktøyvedlikeholder får en ny kompatibilitetsjobb, mens brukere oppdager at versjonskontrollen deres nå trenger versjonskontroll. Foreløpig, test din vert og verktøy før du velger det nye formatet for et
2:44 prosjekt. Eksisterende team kan beholde sitt nåværende format mens økosystemet henter seg inn. I mellomtiden nådde Pi versjon 1.0.
Hva overlever et krasj i Pi Durable?
2:51 Det er en koding agent-sele fra Earendil, med native MCP-støtte gjennom Codemode og verktøy lastet når de trengs. Teamet kaller minimalisme poenget. Hvis agentoppsettet ditt allerede ligner en liten regjering, å holde verktøy utenfor ledeteksten til de trengs, høres ut som en administrativ reform. Den ga også ut Pi Durable, et separat eksperimentelt rammeverk. Oppgaver lagrer sjekkpunkter slik at en omstartet prosess kan fortsette uferdig arbeid fra permanent lagring. Den avgjørende detaljen er verktøy-gjenspilling.
3:16 Et verktøy avbrutt av et krasj kjøres bare på nytt når det erklærer det trygt. Ellers blir modellen fortalt at den ble avbrutt. Det er en nyttig grense når et verktøy kan bruke penger. Jeg vil at assistenten skal huske min handleliste uten å feire et krasj ved å kjøpe den to ganger.
Hva migrerer SvelteKit 3 for deg?
3:30 SvelteKit 3 landet også på torsdag, og flyttet konfigurasjon til Vite og erstattet dollar lib med hash lib, ved å bruke standard pakkens underbane-importer. Migreringskommandoen omskriver det den kan og etterlater en huskeliste for resten. Roboten din kan hjelpe, og din diff fortjener fortsatt å leses. Kunngjøringen rekrutterer til og med robotvennene dine for restene. Vi nærmer oss punktet der en rammeverksoppgradering sender lekser og en foreslått vikar. Og fjernfunksjoner trenger fortsatt eksperimentell Async Svelte.
3:56 Et hovedversjonsnummer føles betryggende, men individuelle funksjoner bærer sine egne modenhetsmerker. Sjekk de du faktisk bruker.
Hva beviser GitHubs fungerende unntak?
4:03 Så hvem er klar for Gits nye format? Her er det unntaket. Et offentlig GitHub-repositorium som inneholder Brian Carlsons foredrag, returnerer allerede et fullt SHA-256 objektnavn. Jeg sjekket den offentlige fjernkontrollen direkte. Foredragets lysbilder kaller støtte en privat forhåndsvisning og sier at opprettelse av repositorium fortsatt kommer. Det er faktisk fremgang bak venterommet. Det beviser at GitHub kan betjene dette forhåndsvisningsrepositoriet.
4:24 Det gir oss ingen garanti for at vanlig prosjektoppretting eller alle dine integrasjoner er klare. Unntaket har en tillatelsesgrense. Hvis du heller vil lese dette enn å høre meg si det, lander diffen i innboksen din hver morgen, gratis på thedailydiff.dev, lenke nedenfor. Så dagens dom er NEEDS REVIEW.
Hvorfor avhenger min dom av hele verktøykjeden?
4:40 Jeg ville beholde det sterkere hash-alternativet, og teste hele verktøykjeden før jeg endrer standarder. Kompatibilitet er en del av å levere sikkerhetsforbedringen. Og det er diffen for i dag. Jeg er Niko fra Axrisi. Flett ansvarlig.
Kilder
- 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



