NixOS-i jaotises kasutatavate nixpkgs pakettide hoidlas on pakutud korduvate ehituste režiim, mis võimaldab tuvastada koodis tagasitõuketehnoloogiate juurutamise juhtumeid, mis sarnanevad XZ projekti intsidentidega. Esitatud kaitsemeetod võimaldab tuvastada muudatusi väljaku allikaarhivides, mida ei leidu koodi hoidlates.
Meetodi olemus seisneb selles, et uue versiooni rakenduse lähtekood ehitatakse kaks korda — esmakordselt git-hoidlast laaditud koodist ja teist korda valmis arhivides levitatavast koodist. Kui ehitustulemused erinevad, on see põhjus kahtlustada salajaseid muudatusi hoidlas või koodiarhivides.
Käesolevaga tuletame meelde, et XZ projekti puhul ei sisaldanud koodi hoidla kahtlasi muudatusi. Tagurpidi moodustavad pahatahtlikud komponendid tarniti XZ dekompresori töökorralduse testimiskomplekti failide vahel. Tagurpidi aktiveeriti ehitussüsteemi tasemel, samas kui XZ algne kood vastas hoidla koodile. Tagurpidi aktiveerivad m4-makrosid Automake tööriistade jaoks olid lisatud ainult valmis arhiivi koodiga ja puudusid hoidlas.
XZ-sse oli tagurpidi sisestatud ründaja, kes oli saavutanud projekti hooldaja staatuse. Tagurpidi sisestamine jäi koheselt märkamatuks, kuna jaotised koguvad põhiliselt pakette, laadides koodi valmis arhiividest, kuna koodi laadimise korral piisab ainult ühe kontrollsummaga, et kontrollida arhiivifaili terviklikkust ja kasutada peeglite süsteemi. Koodi kontrollimisel keskendutakse peamiselt hoidla sisu analüüsile, mistõttu arhiivide ebamugavad erinevused ei pruugi alati koheselt ilmneda.
Failide arhiivide ja repositooriumi lõike vastavuse kontrollimise lihtsustamiseks on mõned avatud projektid, nagu PostgreSQL, rakendanud korduvate arhiivide genereerimise süsteemi. Antud juhul on olemas tööriistakomplekt, mis võimaldab iseseisvalt koodist oma arhiivi kokku panna, mis vastab täielikult allalaadimiseks kättesaadava valmis arhiiviga. Kui iseseisvalt loodud arhiiv ja põhiprojekti pakutav arhiiv erinevad, siis on tegemist repositooriumi või standardarhiivi kompromiteerimisega.
Probleem on selles, et sellist meetodit kasutatakse vaid harvadel juhtudel, samas kui paljud projektid jätkavad täiendavate artefaktide, näiteks man-lehtede, dokumentatsiooni, näidiste, distributiivide paketiscripts ja täiendavate koostamisfailide lisamist arhiividesse. Enamasti toimub see ajalooliste põhjuste ja väljaannete koostamise protsesside eripära tõttu. Lihtne repositooriumi sisu ja arhiivi vastavuse kontrollimine ei sobi sellisel juhul.
Kuidas on ette nähtud koguda vabastamise binaarfaile, nii hoidlast (näiteks võib kasutada automaatselt genereeritud GitHub arhiivi vabastamise sildi jaoks) kui ka hooldaja ettevalmistatud arhiivist ning võrreldes seejärel tulemust. Eksperimendi käigus on sarnase kontrolli lisamine praegu ette nähtud ainult «xz» paketile. Kui eksperiment osutub edukaks, kavatsetakse kontrolli kasutada ka teistes paketides nixpkgs.
Allikas: opennet.ru
