Vlákno názorů k článku
V balíčku xz-utils se objevil backdoor
od cc - 2 roky plánování, zneužití toho, že původní autor...
-
2 roky plánování, zneužití toho, že původní autor xz měl psychycké problémy, a postupné přebrání projektu vyústilo v kompromitovaný release, který použil binární data v testech! Toto nebyl někdo, kdo by chtěl rychle prachy, toto byl někdo s obrovskou trpělivostí a měl dlouhodobý plán.
Nejvíc absurdní na tom je, že se na to přišlo jen kvůli tomu, že ten backdoor hodně vytěžoval CPU. Kdyby byl dobře napsaný tak to možná nikdo nezjistil.
-
tak jak se projevoval je velice pravděpodobné, že by se to zjistilo, ale chvilku by to trvalo.
Tohle není amatérská práce někoho, kdo něco zkouší. Může to být je jeden z mnoha pokusů infiltrovat open source, stačí chvilku sekat dobrotu a příjmou tě všudemožně.
Binární kódy, nečitelné věci, asm jsou největší problém a je čímdál složitější se tomu vyhnout, kdejaký kód takové věci obsahuje.
-
DannyStříbrný podporovatelZ druhe strany se ale vytraci ty low-level znalosti a hlavne... moc se u vseho specha. Chceme to mit jednoduche a taky rychle, spousta veci se automatizuje (nic proti), ale v takovem prostredi neco take snadneji proklouzne. Slabinou tohohle systemu je cela filozofie...
Mimochodem systemova dira jsou i samotne "releases" na githubu - kdy system umozni vyvojari nahrat archiv, co vlastne ani nema obraz v repozitari. Aneb ano, zase si nekdo nekde neco usnadnil.
-
> Mimochodem systemova dira jsou i samotne "releases" na githubu - kdy system umozni vyvojari nahrat archiv, co vlastne ani nema obraz v repozitari. Aneb ano, zase si nekdo nekde neco usnadnil.
U projektů používající Autotools je bohužel obvyklé, že ten tarball obsahuje spoustu věcí navíc, protože postup je takový, že se nejdříve spustí nějaké ty autoconf, automake atd., a až pak se z toho vyrobí ten archiv.
-
DannyStříbrný podporovatel
Smutny je, ze i ty distribuce si usnadnuji zivot a ty autotools se v procesu prejimani od zdroje preskoci, kdyz jim nekdo ten predzvykany tarball predhodi. Pritom zrovna tohle bezi casto dost automatizovane a tech par kroku navic by nikoho nezabilo....
Ono popravde i revidovat to, co se vubec deje behem testu by chtelo. Tyhle pasaze jsou dosti opomijene a prehlizene - a asi prave proto, ze jde prece "jenom" o testy... a zrovna u toho xz, kde v ramci testu byl uzit ruzny binarni bordel, ktery slo pouzit pro ovlivneni toho, co se deje v ramci buildu deje se to ukazalo jako pekna achilova pata. A schovavacka je to pekna...
-
Těch pár kroků často hejbe násobě s časem buildu a zanáší další ošemetnosti, ne vždy totiž ten tarball je identický se stavem v repu, mno a vlastně o tom je i tenhle problém.
ano a testy se spouští ve stejném systému (a dokonce ve stejné pipelajn) jako samotný build, už nejednou se stalo, že test ovlivnil výsledek, teď je to další ukázka.
Binární bordel v testech je poměrně častý a ne vždy je možné se ho snadno zbavit.
-
DannyStříbrný podporovatel
No je treba otazka, jestli veskery binarni odpad (a tedy veskere testy) jsou skutecne nezbytne pro potreby produkcniho sestaveni... i tady by se hodil KISS pristup. Cim slozitejsi cely ten proces bude, tim vetsi prostor pro podobne "schovky".
-
Filip JirsákStříbrný podporovatelDanny: Jasně, budou se jednotkové testy udržovat v separátním git repository mimo hlavní zdroje. To by vývoji velmi pomohlo 🤦
-
DannyStříbrný podporovatel
Ale houby, zas tam ctete neco, co nikdo nenapsal. A videl jste nekdy Makefile, pane vyvojar? Ono zalezi, jak si ho zavolate... a podle toho se neco (ne)spusti. A rozhodne neplati, ze vsechno potrebujete nutne spustit proto, abyste jen ziskal fungujici binarku.
-
oddělení kontextů nemusím řešit pouze vlastními repy, mohu část nespustit nebo dokonce před buildem některé složky smazat.
Pro lepší automatizaci a kontrolu obsahu je ale dobré opravdu testy, které potřebují netriviální závislosti držet ve vlastním repu. Tím jasně řekneš, že se ani nemusí stahovat a pracovat s nimi při produkčním buildu.
Už dnes to je pravidlem u spousty projektů, protože testy často ani nedodržují code style, používají konstrukce, které mohou být nebezpečné a nemusí splňovat podmínky či projít statickými testy. Mluvím zejména o různých integračních, systémových, akceptačních, black box testech.
