Reprodukálható buildek a Tails-től

 ( trey | 2017. november 16., csütörtök - 10:53 )

A Tails projekt bejelentette, hogy azonos nevű terjesztésük ISO lemezképfájljai immár reprodukálhatók a Tails 3.3-as kiadástól kezdve. Ezzel a Tails egyike lett azon Linux operációs rendszer terjesztőknek, akik ezt elsőként el tudták érni. Hogy mi is az a reprodukálható build és ennek hol van szerepel, mik az előnyei, arról részletesen itt lehet olvasni.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

reprodukálható build... egyszer nekikezdtem ilyen linuxot építeni, kb. az X11-ig jutottam el. Aztán lemezhiba és időhiány miatt felfüggesztettem a dolgot.
Előtte csomagonként építgettem fel egyet, és sajnos nem dokumentáltam a dolgot, így amikor néhány csomagot újabbra akartam cserélni, igencsak szívás volt.

Sőt, én odáig is eljutottam, ha elhasal a build, a hibás csomag kijavítása után, folytatható a build... attól a csomagtól indulva.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

teljesen reprodukálható build már volt az uhuban tíz éve :)

Bitre pontosan ugyanzt a binarist adta? (Azt erosen ketlem, mert Debianosok is eleg sokat szivtak, szivnak meg mindig azzal, hogy tenyleg teljesen reprodukalhato legyen.)

--
|8]

Nekünk eleve a teljes reprodukálhatóság volt a cél az elejétől. Bitre pontosan csak azért nem csináltunk azonosat, mert inkább benne hagytunk buildeléshez kapcsolódó debug és timestamp infókat, de ami volt különség az csak ilyenek voltak.

Akkor az nem teljesen reprodukalhato. A teljes reprodukalhatosagnak pont az a celja, hogy biztos tudjak lenni benne, hogy a binaris csomag ugyanaz, amit magam is forditani tudnek. Ha nalam mas jon ki, akkor kutakodhatok, hogy mi a kulonbseg, ami az egesz dolog hasznossagat megoli. (Es nem, nem fogom elhinni senkinek, hogy csak debug info & timestamp a kulonbseg.)

--
|8]

Ubuntut használok, épp Artfult.

Pozitív meglepetés most hirtelenjében, hogy (első blikkre) úgy fest, hogy a deb-ben ábécében vannak a fájlok. Az agyam felbaszta, hogy a "dpkg -L" kimenetét pipe-olnom kellett, vagy fejben átnézni rengetegszer. Biztos vagyok benne, hogy a közelmúltig nem így volt, elég friss változás lehet. Az UHU-ban ábécében voltak.

Nem értek Ubuntu csomag újrafordításához. Guglizok. Csomó nagyjából hasonló, de azért eltérű tartalmú oldal jön szembe. Mindegyik a telepített csomagok között, saját useremmel, saját környezetemben fordít. Mindössze annyi garantált, hogy legalább a fordításhoz szükséges csomagok telepítve vannak.

Az UHU-ban volt olyan, hogy megfogtuk, hogy egy plusz (elvileg irreleváns) csomag feltelepítése eredményezett hibás fordítást. Ilyet a Debian hogyan kezel?

Minap GTK+-t akartam újrafordítani, egy hibajavítást kipróbálandó. Követtem az utasításokat. Sok-sok parancs egymás után. Elhasalt a fordítás. Belehegesztettem (hagyja ki a teszteket vagy valami ilyesmi), továbbment, máshol is elhasalt, arra nem volt hirtelen ötletem. Kipróbáltam friss userrel. Ugyanott elhasalt elsőre, belehegesztettem, továbbment, befejeződött sikeresen. Kösz szépen, remek!

Ez UHU-ban úgy néz ki, hogy egyetlen parancs felhúzott egy chroot-ot, amelyben pontosan az adott csomag fordításához megadott függőségek tranzitív lezártjai voltak, se több, se kevesebb, ott fordított, és a végén tutkó megbízhatóan ott volt a kész csomag.

Párhuzamos fordítást használ a Debian/Ubuntu? Nekem úgy tűnt, a GTK+ fordítása közben is, hogy igen. Kontrollálhatatlan, reprodukálhatatlan, soha nem tudhatod, hogy hol van egy hiányzó függőség, egy hibásan megírt Makefile, amellyel az esetek elenyésző kis részében úgy jön ki az időzítés, hogy elhasal (vagy még rosszabb: hibás eredményt ad) a fordítás, mert kivételesen egy másik task lett kész hamarabb. Az UHU-ban szigorúan egy szálon fordult minden csomag, a gépeink több processzorát/magját több csomag egyidejű fordítására használtuk.

Amúgy, még 1 szálon is ért minket meglepetés: volt olyan csomag, ahol a másodperc alapú időcímke egyezése vagy eltérése okozott sikeres vagy sikertelen fordítást, kellett egy jól irányzott "sleep 1.1" valahova.

Biztos nem volt tökéletes amit csináltunk. Nem volt diffelés a végén az előző csomaghoz képest, hogy mik az új, megszűnt fájlok, melyek változtak stb. Mégis, jóval előbb felismertük a reprodukálható fordításra való igényt mint a nagyok, és szarakodás helyett megtettük a főbb lépéseket. Állítom, hogy a gyakorlatban tíz (bocs, van az közel 15 is) évvel ezelőtt jobban működött az UHU-ban, mint az Ubuntuban most.

PS. Igen, picit mást értünk "reprodukálható" alatt. Nem egészen ugyanaz az az elvárás, hogy atombiztosan leforduljon (elhasalás stb. nélkül), és az, hogy bitre ugyanaz a csomag álljon elő.

Szerk:

Amúgy a kedvencem az volt, hogy a dpkg vagy Debian fejlesztőinek (nem emlékszem kiknek pontosan) jeleztük, hogy jó volna ábécérendbe rakni a fájlokat, ez és az és amaz lenne az előnye (például a hatékony rsync-elhetőségnek ez az egyik előfeltétele), és hogy mi hogyan oldottuk meg, mire lepattintottak azzal, hogy féltek hogy túlzottan erőforrásigényes (!?!?!?!) ez a művelet. Éééérted, kattog a bash (./configure) meg fordít és optimalizál a gcc, assembler, linker, man2doc, msgfmt, anyámkínja hogy elkészítse a fájlokat, melyeket még jól be is kell mindjárt tömöríteni, de előtte név szerint ábécébe rakni őket erőforrásigényes!!! Komolyan.

Idézet:
Nem értek Ubuntu csomag újrafordításához. Guglizok. Csomó nagyjából hasonló, de azért eltérű tartalmú oldal jön szembe. Mindegyik a telepített csomagok között, saját useremmel, saját környezetemben fordít. Mindössze annyi garantált, hogy legalább a fordításhoz szükséges csomagok telepítve vannak.

sbuild, pbuilder, stb. Egyebkent https://wiki.debian.org/ReproducibleBuilds oldalon lehet tajekozodni, hogy Debian tajan ez mit jelent, es hogyan all ossze, illetve https://tests.reproducible-builds.org/debian/reproducible.html oldalon latszik az akutalis statusz, valamint https://tracker.debian.org/pkg/riemann-c-client (illetve https://tracker.debian.org/<csomagnev>) alatt is ott a reproducible link, amin rogton latni lehet, hogy az adott csomag reprodukalhatoan buildelodik-e.

Idézet:
Az UHU-ban volt olyan, hogy megfogtuk, hogy egy plusz (elvileg irreleváns) csomag feltelepítése eredményezett hibás fordítást. Ilyet a Debian hogyan kezel?

Automatizmus nincs ra, tudtommal, bar a reproducible-builds toolok biztosan alkalmasak arra, hogy diffeljek a forditasi kornyezetet. Ha egy ilyen elojon, akkor Build-Conflicts lehet egy megoldas.

Idézet:
Ez UHU-ban úgy néz ki, hogy egyetlen parancs felhúzott egy chroot-ot, amelyben pontosan az adott csomag fordításához megadott függőségek tranzitív lezártjai voltak, se több, se kevesebb, ott fordított, és a végén tutkó megbízhatóan ott volt a kész csomag.

Ez Debianban is igy van. Azzal a kulonbseggel, hogy van tobb tool is ami kvazi ugyanezt megcsinalja: sbuild, pbuilder, stb. A mukodesi elv nagyon hasonlo: tiszta chrootban fordit. A kulonbsegek ott vannak, hogy mikent all ossze ez a chroot. A debianos buildd-k sbuildet hasznalnak, ugy nagyjabol... nem is tudom, kozel 20 eve.

Idézet:
Párhuzamos fordítást használ a Debian/Ubuntu? Nekem úgy tűnt, a GTK+ fordítása közben is, hogy igen. Kontrollálhatatlan, reprodukálhatatlan, soha nem tudhatod, hogy hol van egy hiányzó függőség, egy hibásan megírt Makefile, amellyel az esetek elenyésző kis részében úgy jön ki az időzítés, hogy elhasal (vagy még rosszabb: hibás eredményt ad) a fordítás, mert kivételesen egy másik task lett kész hamarabb. Az UHU-ban szigorúan egy szálon fordult minden csomag, a gépeink több processzorát/magját több csomag egyidejű fordítására használtuk.

Hasznal, es piszkosul mindegy hol hasal el, es hogyan. A reprodukalhato buildeles lenyege, hogy sikeres buildet reprodukaljon, mert sikeres buildekbol all ossze a distro. Ketsegtelen, lehetnek igy forditasi hibak, ezt jo esetben a test suite megfogja. Ha nem, bugreport, es lehet vele kezdeni valamit (pl parhuzamos forditast kikapcsolni). Tapasztalatom szerint azert mara mar a legtobb csomagban sikerult megoldani, hogy lehessen ertelmesen parhuzamosan buildelni, es ne legyen belole para.

Idézet:
Állítom, hogy a gyakorlatban tíz (bocs, van az közel 15 is) évvel ezelőtt jobban működött az UHU-ban, mint az Ubuntuban most.

Nem vitatom, hogy jo iranyba indult az UHU, azt sem, hogy tette ezt joval a nagyok elott. Azt vitatom, hogy ugyanazt erte-e el (nem, mert amennyire kiveszem a szavaidbol, mas volt a cel). Az Ubuntut sem ismerem, hogy mikent all e temaban. Debian - fentebbi linkek alapjan - eleg kemenyen rafekudt a temara, es alapos tesztek vannak, amik automatikusan minden egyes feltoltest ellenoriznek. Ketlem, hogy az UHU 15 evvel ezelott itt tartott volna.

--
|8]

> > Az UHU-ban volt olyan, hogy megfogtuk, hogy egy plusz (elvileg irreleváns) csomag feltelepítése eredményezett hibás fordítást. Ilyet a Debian hogyan kezel?
> Automatizmus nincs ra, tudtommal, bar a reproducible-builds toolok biztosan alkalmasak arra, hogy diffeljek a forditasi kornyezetet. Ha egy ilyen elojon, akkor Build-Conflicts lehet egy megoldas.

De eleve hogy jöhetne létre olyan környezet, amin build-conficts segít? Ha egyszer a környezet reprodukálható, akkor definíció szerint mindig ugyan azt tartalmazza, tehát lehetetlen, hogy "véletlenül" (???) bekerül(het???) valami "plusz" csomag amit ezzel kell kivédeni(???).

> > Ez UHU-ban úgy néz ki, hogy egyetlen parancs felhúzott egy chroot-ot, amelyben pontosan az adott csomag fordításához megadott függőségek tranzitív lezártjai voltak, se több, se kevesebb, ott fordított, és a végén tutkó megbízhatóan ott volt a kész csomag.
> Ez Debianban is igy van. Azzal a kulonbseggel, hogy van tobb tool is ami kvazi ugyanezt megcsinalja: sbuild, pbuilder, stb. A mukodesi elv nagyon hasonlo: tiszta chrootban fordit. A kulonbsegek ott vannak, hogy mikent all ossze ez a chroot. A debianos buildd-k sbuildet hasznalnak, ugy nagyjabol... nem is tudom, kozel 20 eve.

Erősen úgy rémlik nekem, hogy a debian szerverekre a maintainerek által valahogy lefordított csomagok (is) kerültek fel.
Amúgy ha van több build tool is, akkor a reprodukálhatósághoz kell azzal az addicionális információval rendelkezned, hogy melyik tool generálta amit ellenőrizni szeretnél.

> Tapasztalatom szerint azert mara mar a legtobb csomagban sikerult megoldani, hogy lehessen ertelmesen parhuzamosan buildelni, es ne legyen belole para.

Szerintem is elég jó a helyzet már, de ez régen volt és ez a többszálú fordítés kérdés csak egy apróság volt az egészben.

> Ketlem, hogy az UHU 15 evvel ezelott itt tartott volna.

Nem értem miért kétled ezt, amikor állítjuk, úgy mint akik beleástunk magunkat mélyen a konkrét témába. Sok mindent lehet vitatni az uhuval kapcsolatban, de ez azon dolgok egyike, amit másokhoz képest sokkal jobban oldottunk meg.

Sajnos a piacon nem a technológiailag előnyös dolgok terjednek el általában és érnek el penetrációt, hanem a fontos emberek csillagjainak együttállása (kedvük, érdekük, szükségleteik stb). Úgyhogy sajnálom.

A munkát megcsináltuk, csak nem pont ugyan ez volt a cél. Az te célodat az uhuban tíz éve triviális lett volna elérni, csak éppen erre senkinek nem volt akkor tényleges igénye, mi a build tökéletességre törekedtünk, azt el is értük, és ez lefedte a te célod 99%-át. Csak azt akartam jelezni finomam, hogy nem tekinteném 2017 végén a világ csodájának az automata reprodukálható buildet, mindenkinek illene legalább ilyen közel lenni hozzá. Amikor pedig a 100% azonos build a cél valami speciális okból az pedig minimális lépés kell legyen, aminek a hír értéke pont nulla kéne legyen.
Amúgy halkan megjegyzem, hogy ha csak nem te magad építed a processzorodat és az egyéb alkatrészeket akkor soha nem lehetsz biztos semmiben, tehát 100% megoldás nem is létezik. Gondolj bele, eleve mindenki úgy kezdi, hogy _valamikor_ _valamilyen_ binárisok használatával elindul, ráadásul ez még messze nem a legalsó réteg amiben el lehet rejteni bármit. Lásd pl: http://scienceblogs.com/goodmath/2007/04/15/strange-loops-dennis-ritchie-a/

Még annyival egészíteném ki, hogy az uhuban a bináris fileok reprodukálhatóak voltak egyébként, csak a metaadatokban (amiket viszont tartalmaztak bináris csomagok is) voltak különbségek buildenként. Talán így érhetőbb. Ráadásul volt olyan feature is a build rendszerben, hogy direkt figyelte, hogy van-e érdemi változás az új rebuild után az adott csomagban, és ha nem volt, akkor nem is került ki az új csomag, mert fölösleges lett volna bárhol is újratelepíteni a csomagot ami pont ugyan az mint az előző verzió. Viszont ha mégis változott valamiért (pl mert az újrafordítás során más verziójú gcc-t használtunk, de ezer más szándékos és nem szándékos oka lehetett), akkor azt egyrészt láttuk, másrészt eleve új verziószámot kapott, pont azért, hogy egyértelmű legyen, hogy az már bizony egy más tartalmú csomag. A csomag verziószám viszont már a bináris csomag része, és azt ugye fordítás előtt kell megadni, és mivel ez sokkal gyakoribb eset volt, mi nem is akartunk ugyan azzal a régi verziószámmal buildelni, emiatt sem lehetett soha bináris szinten ugyan az két csomag. De mondom, arra megvolt a toolset, hogy ellenőrizze, hogy egyébként metainformációkon kívül tényleg egyeznek-e a csomagok. És tényleg sokat tettünk az egységesítésért, pl a fileok időcímkéje sem a tényleges build idejétől függött.

Malware elrejtésre egy másik remek ötlettárház az Underhanded C Contest.

Nem, nem csinaltatok meg. Elertetek, hogy megfelelo kornyezetet felhuzva a csomag biztosan leforduljon. Ezt a Debian is tudta 20 eve. Az, hogy bitre ugyanaz forduljon, kellenek azok az eszkozok, amikkel ugyanazt a kornyezetet elo tudod allitani. Amennyire UHU-ra emlekszem, ez nem volt meg. Kell az, hogy a csomagok ne rakjanak magukba mindenfele timestampeket, datumokat, stb. Kellenek az eszkozok, amikkel ellenorizni tudod, hogy egyreszt a forditasi kornyezet felhuzhato, hogy a build lefut, es ugyanazt produkalja-e. Az, hogy egy releasen belul minden atomstabilan lefordul, nagyon messze van ettol.

Kornyezet eloallitasnal itt gondolok olyanra is, hogy pl. xyz-1.0-2-vel fordult a csomag, de a distro vegul -3-al releaselt, akkor ossze lehessen rakni olyan chrootot, amiben -2 van, mert ugyanarra a kornyezetre van szukseg, nem pedig csak hasonlora/kompatibilisre.

--
|8]

Rosszul emlékszel, minden pontosan megvolt és használtuk is. Igazából úgy is mondhatnám, hogy az történt, hogy megcsináltuk a tökéletesen reprodukálható buildeket, majd ezen túllépve még hozzáadtunk némi debug infot. Pont az volt a lényeg, hogy ellentétben minden más disztribúció build rendszerével, mi tökéletesen konzisztensen reprodukálható környezetben dolgoztunk. Már írtam fent, hogy konkrétan minden csomag build végén lefutott az a script részlet, ami megnézte, hogy a timestampeken és a csomagban található build információkón kívül minden pontosan ugyan az-e az újonnan buildelt bináris csomagban mint az előző verzióban. Az atomstabil buildelés úgy jön ide, hogy nekünk a végső célunk az volt, és a reprodukálható build ennek előfeltétele, tehát meg kellett és meg is ugrottuk. Az utolsó mondatoddal egyetértek, ez az amit az uhuhoz megcsináltunk, és most hallok először arról, hogy valaki más is ilyenen dolgozik.