Git 3.0 ja SHA-256: Miks tarkvaramaailma vundament mureneb?

Git 3.0 toob endaga kaasa fundamentaalse muudatuse, asendades senise SHA-1-räsimisalgoritmi turvalisema SHA-256-ga. See üleminek, mis on ajendatud pigem riiklikest turvanõuetest kui vahetust ohust, muudab uute hoidlate vaikeväärtusi ja võib lõhkuda aastakümnete pikkuseid automatiseerimisskripte. Samal ajal kui GitLab on juba eksperimentaalset tuge pakkumas, jäävad suured platvormid nagu GitHub veel ootelehele, tekitades tarkvaraarenduse maailma ootamatu lõhe.

Kaks erinevat faili, üks identne sõrmejälg

2017. aasta veebruaris avaldasid Google'i turvauurijad teadustöö, millele olid lisatud kaks PDF-faili. Kui sa need failid alla laadid ja avad, näed sa täiesti erinevat sisu. Üks on sinine, teine on roheline; üks ütleb üht, teine teist. Aga siin on see kummaline osa: kui sa söödad need failid ette SHA-1-algoritmile — sellele samale matemaatilisele „sõrmejäljeandjale“, mis on olnud Giti vundamenti sisse ehitatud ajast, mil Linus Torvalds 2005. aastal selle esimesed read kirjutas —, saad sa vastuseks täpselt identse koodirea. Mitte sarnase. Identse.

See on sündmus, mis pidi olema praktilises maailmas võimatu. See on nagu kohtaksid tänaval kahte inimest, kes näevad välja täiesti erinevad, aga kellel on viimse kurruni täpselt samasugused sõrmejäljed. Krüptograafid ristisid selle ründe nimega SHAttered ning see ei olnud niivõrd üllatus kui ametlik matusekuulutus ühele vananevale tehnoloogiale.

SHA-1-muremõrad olid näha juba varem. 2015. aastal nägime me intsidenti nimega SHAppening ja 2020. aastal lükkas rünnak nimega Shambles kirstukaane veelgi sügavamale mulla alla. See, mis oli kunagi teoreetiline matemaatiline nõrkus, muutus demonstratsiooniks, seejärel odavaks ründeks ja lõpuks piinlikkuseks. USA riiklik standardite ja tehnoloogia instituut NIST nägi seda ette juba 2011. aastal ja kuulutas SHA-1 ebasoovitavaks. Täna on selle kasutamine FIPS 140-2-sertifitseeritud keskkondades — see on turvastandard, mida valitsused ja tõelised suurettevõtted peavad järgima — lausa keelatud.

Kuid hold that thought, sest siin on asja paradoks: ükski neist rünnakutest ei murdnud Giti tegelikus igapäevatöös. Git kasutab SHA-1-algoritmi andmete tervikluse kontrollimiseks, mitte autentimiseks. See on nagu sildilugeja, mitte lukuabi. Aga „see pole veel katki läinud“ on ebamugav lause, mida kirjutada vastavusdeklaratsiooni, ja regulaatorid ei aktsepteeri seda argumendina. Surve liikuda uue lahenduse poole oli reaalne, struktuurne ja vältimatu.

Uus asendaja, SHA-256, tekitab 256-bitise sõrmejälje võrreldes SHA-1 senise 160 bitiga. See on fundamentaalselt keerulisem matemaatiline pähkel, mida purustada. Ja 2026. aastaks on võrdlustestid näidanud, et see töötab neli korda kiiremini kui MD5 — üks veelgi vanem algoritm, mille SHA-256 on ammu selja taha jätnud. Paberil on see valik lihtne. Praktikas on see koht, kus asjad muutuvad tõeliselt keeruliseks.

Kuidas Git õppis numbrit usaldama

Kui Linus Torvalds 2005. aastal Giti lõi, ei valinud ta SHA-1-algoritmi seetõttu, et ta ehitas pangaseifi. Ta vajas lihtsalt usaldusväärset silti. See eristus on oluline. Räsi ehk hash oli Giti algses disainis tervikluse kontroll — viis kinnitada, et fail, mille sa kätte said, on täpselt seesama fail, mille keegi teele saatis, mitte lukk, mis kaitseb aaret vaenlase eest. SHA-1 oli toona kiire, lühike ja ausate andmete puhul praktiliselt põrkumistevaba. Sellest piisas.

Mehhanism, mille Git selle sildi ümber ehitas, kannab nime sisuaadressitav mälu (content-addressable storage). See on elegantne ja samas veidi peadpööritav kontseptsioon. Kujutle raamatukogu, kus pole ühtegi kataloogi autorite ega pealkirjade järgi. Selle asemel on iga raamatu nimeks tema enda sisu täpne räsi. Kui sa muudad raamatus kasvõi ühte tähte, muutub ka selle nimi. Git jälgib kõike — failide sisu, kataloogide seisundeid, muudatuste ajalugu — just nende räside abil.

Sa leiad muudatuse (commit) üles samamoodi nagu sõna sõnastikust: selle nime järgi, mis on tuletatud otse sisust. Kui muudad failis ühe baidi, muutub räsi, mis muudab muudatuse identifikaatorit, mis omakorda muudab iga järgnevat lüli ahelas. Ajalugu ongi räsi.

See elegants ongi põhjus, miks SHA-256-le üleminek on nii struktuurselt hävitav. SHA-256 räsi on 64 kuueteistkümnendsüsteemis märki pikk; SHA-1 oma on vaid 40 märki. See 60-protsendiline pikkuse kasv ei ole lihtsalt salvestusruumi detail. See pikkus on sisse kirjutatud igasse skripti, igasse API vastusesse ja igasse regulaaravaldisse (regex), mille keegi on kunagi kirjutanud eeldusel, et identifikaator on täpselt 40 märki pikk. Git on pakkunud SHA-256 tuge valikulise eksperimendina alates 2020. aasta versioonist 2.29. Aga Git 3.0 ei lisa lihtsalt uut valikut — see muudab vaikeväärtust iga uue hoidla jaoks, mis luuakse käsklusega git init. See on juba hoopis teist masti samm.

Mida Git 3.0 tegelikult muudab — ja millest ta vaikselt loobub

See migratsioon teeb ühte asja väga häälekalt ja mitut asja üsna vaikselt. Häälekas osa: iga uus hoidla hakkab vaikimisi kasutama SHA-256-algoritmi, genereerides 64-kohalisi identifikaatoreid nende 40-kohaliste asemel, mis on olnud versioonihalduse pulsisageduseks juba kaks aastakümmet. Vaikne osa on aga korralik suurpuhastus pärandvarast.

Seitse vana käsklust eemaldatakse täielikult. Peaharu vaikenimi muutub ametlikult masterist mainiks — muudatus, mis on ollut vabatahtlik alates 2020. aastast, on nüüd lihtsalt reegel. Samuti asendab uue põlvkonna Reftable-mälu vana lamedate failide süsteemi. See on praktiline vajadus, sest 256-bitiste räside salvestamine ja nendes navigeerimine tänapäeva hiiglaslikes hoidlates nõuab midagi palju efektiivsemat kui see formaat, mille Git 2005. aastal päranduseks sai.

Üks muudatus võib üllatada neid arendajaid, kes eelistavad koodi ise kompileerida: Git 3.0 ehitamine nõuab nüüd Rusti tööriistahelat. See pole lihtsalt üks lisasõltuvus. See on märk sellest, kuhu tarkvara vundament liigub — sama järkjärguline nihe toimub ka Linuxi tuumas, Androidi platvormil ja paljudes teistes süsteemsetes tarkvarades.

Peatume hetkeks Reftable'i juures. Mõtle vanast viitesüsteemist kui arhiivikapist, kus iga harunimi vastab eraldi paberlipikule kirjutatud räsile. See töötas 2005. aasta mõõtkavas suurepäraselt. Aga monorepode ajastul, kus on tuhandeid harusid ja igal pool 64-kohalised räsid, muutub see kapi sahtlites tuhnimine aeglaseks. Reftable asendab selle sahtli indekseeritud registriga, mis on disainitud uue aritmeetika jaoks.

Ükski neist muudatustest pole saladus, kuid kokkuvõttes maanduvad need väga erinevalt, sõltuvalt sellest, kus sa selles ökosüsteemis asud.

Kaks maailma, mis ei räägi sama keelt

Kujutle kahte arhivaari, kes töötavad samas hoones. Üks tähistab iga dokumendi 40-kohalise koodiga, teine 64-kohalisega. Kui ulatad faili ühe laua juurest teisele, jooksevad mõlemad süsteemid kokku. Kumbki kood ei kattu teisega. See ei ole metafoor, mis lähemal uurimisel koost laguneks — see on peaaegu täpne kirjeldus sellest, mis juhtub, kui SHA-256-hoidla proovib andmeid saata SHA-1-hoidlasse või sealt vastu võtta. Objektide nimed lihtsalt ei vasta üksteisele.

Git pakub küll kitsast silda. Indeksfailid toetavad kahepoolset vastandamist SHA-1 ja SHA-256 nimede vahel, nii et teoreetiliselt on tõlkekiht kahe maailma vahel võimalik. Aga sõna „teoreetiliselt“ teeb selles lauses väga rasket tööd. See vastandamine on osaline, erijuhtumeid alles kaardistatakse ja arendajad, kes töötavad kahe formaadi ristumiskohas, on sisuliselt need inimesed, kes avastavad omal nahal, kus see sild otsa saab.

Majutusplatvormide olukord muudab pildi veelgi teravamaks. GitLab lisas eksperimentaalse SHA-256-toe 2024. aasta augustis versiooniga 17.3 — see on reaalne samm, isegi kui sõna „eksperimentaalne“ viitab sellele, et kõik konstruktsioonid ei pruugi veel suurt koormust taluda. GitHub ja Bitbucket ei ole aga veel täielikku üldtuge pakkunud. See tähendab, et maailma kaks suurimat platvormi töötavad endiselt eranditult SHA-1 peal.

See ei tekita mitte puhast üleminekut, vaid prao, mis jookseb läbi kogu arendustööriistade ahela. Tiim, mis võtab täna kasutusele SHA-256, seisab silmitsi mitmeaastase perioodiga, kus alamoodulid viitavad SHA-1-projektidele, projektidevahelised muudatussoovid ja CI-torustikud peavad rääkima mõlemat murret korraga. Skriptid, mis eeldavad, et räsi on alati 40 märki, lihtsalt purunevad. Tõlkekiht ahendab seda lõhet, aga ei sule seda. Kui kauaks see lõhe avatuks jääb, on hetkel teadmata.

Turvaargument on lipp, millega lehvitatakse; regulatiivne nõue on aga mootor, mis asja liigutab.

Vastuväide: kui ravim on kallim kui haigus

Scott Chacon aitas GitHubi üles ehitada. Ta tunneb selle süsteemi torustikku paremini kui peaaegu keegi teine elusatest inimestest. Ja tema hinnang SHA-256-vaikeväärtuseks muutmisele ei ole leebe: ta on nimetanud seda kulukaks veaks, mis annab enamikule kasutajatest väga vähe praktilist turvaedu. See ei ole mingi äärepoolne arvamus kelleltki, kes magas maha uudise SHA-1 haavatavusest. See on kaalutletud argument inimeselt, kes on jälginud ökosüsteemi kasvu kaks aastakümnendit ja näeb nüüd, kuidas hakatakse läbi saagima ühte struktuurset tala.

Tema põhipunkt väärib kuulamist. Valdava enamiku arendajate jaoks on reaalne oht, et keegi tekitab Giti hoidlas teadliku räsi-põrkumise, peaaegu teoreetiline. Tegelik surve algoritmi vahetamiseks ei tule keldris istuvalt häkkerilt, vaid vastavuskontrolli ametnikult, kellel on käes kontrollnimekiri. FIPS 140-2-standard keelab SHA-1 täielikult. Suurettevõtted ja valitsuslepingud vajavad seda sertifikaati.

Samal ajal on kaasnev kahju aga käega katsutav. Tuhanded sisemised skriptid ja automaatikad sisaldavad regulaaravaldisi, mis otsivad täpselt 40 märki — nad ei hoiata sind, kui nad katki lähevad. Nad lihtsalt annavad valesid vastuseid või ei tee üldse midagi, ja selle märkamiseks võib kuluda kuid. Alternatiivina pakutud allkirjastatud päiste meetod oleks võinud lisada turvakihi olemasolevale formaadile ilma räsipikkust puutumata — samad aadressid, uus rüü. Selle pooldajad nimetavad seda valimata jäänud teeks. Kas neil on õigus või alahindavad nad SHA-1-haavatavusest juurde jäämise pikaajalist kulu, on küsimus, mille üle kogukond vaidleb veel kaua.

Küsimused, millele pole veel vastust

Git 3.0 üldise kättesaadavuse jaoks pole veel kinnitatud kuupäeva. Esialgne aken on 2026. aasta lõpp, aga sõna „esialgne“ on siin määrava tähtsusega. Keegi pole välja kuulutanud ka ametlikku üleminekutööriista maailma olemasolevate SHA-1-hoidlate migreerimiseks, mis tähendab, et üleminekuplaanis on praegu suur ja märgatav auk.

GitHubi seisukohta on raskem lugeda kui GitLabi oma. GitLab tegi oma sammu 2024. aasta suvel. GitHub ei ole avaldanud ajakava, millal nad oma uurimisfaasist kaugemale liiguvad. Ka Bitbucketi staatus on ebaselge. See tähendab, et kolm platvormi, kus asub lõviosa maailma koodist, ei pruugi olla valmis hetkeks, mil vaikeväärtus lülitub uuele režiimile.

Ka jõudlusküsimus on endiselt õhus. SHA-256 räsid on 64 märki pikad ja iga operatsioon, mida Git teeb, puudutab neid identifikaatoreid. Reaalne kulu protsessori tsüklites ja mälukasutuses, mõõdetuna tõeliste tööstuslike monorepode peal, ei ole veel ammendavalt avaldatud. See, et algoritm on neli korda kiirem kui MD5, on laboratoorne näitaja, mis ei ütle meile suurt midagi selle kohta, mis juhtub siis, kui CI/CD-torustik hakkab räsimisega töötlema miljardeid objekte päevas.

Iga versioon igast projektist, mis on kunagi Giti salvestatud, asub süsteemis, mille alustala on muutumas. Git 3.0 ja SHA-256 dilemma ei lahene vaikeväärtuse muutmise nupule vajutamisega — see alles algab. Selle muutuse lõplik kuju on alles joonistamisel. Minu märkmikus jääb see lehekülg veel avatuks.