Ale však tá škodná nie je v zdrojáku, ale v binárke (Wheels)... zároveň FOSS neznamená väčšiu bezpečnosť, ale väčšiu možnosť overiť si bezpečnosť...U PyPi je problém ako už zaznelo že binárky sa nahrávajú osobitne, namiesto toho aby sa buildovali zo samotných poskytnutých zdrojákov... Ale to nie je chyba FOSS.. to je chyba len samotného PyPi...
Vždyť v článku je jasně napsáno, že ve zdrojovém kódu ten malware vůbec není a je jen v binárních balíčcích vedle. Takže prohlídkou zdrojových souborů se to vůbec nedalo najít a chyba rozhodně není v otevřeném přístupu ke zdrojákům.
Je to chyba konkrétní platformy, která umožňuje nahrát zvlášť zdrojáky a pak něco spustitelného, co mohlo vzniknout jakkoliv a ne sestavením z těch zdrojáků.
Ne, že to volá nějakou binárku, ale že vedle těch zdrojáků leží i nějaká zkompilovaná binárka. A na mou duši, na psí uši je to zkompilované z těch zdrojáků a ne úplně z něčeho jiného. Přísahám na zdraví svých dětí ;)
Takže problém není v open source, ale že PyPi si v některých aspektech na pořádné open source jen hraje.
pokud se bavíme o open source (GPL, MIT, Apache), tak se bavíme o zdrojovém kódu a nikoliv o výsledku nějakého buildu (binárky), to už má/může mít jinou licenci a podmínky použití a třeba binárky pod GPL nelze ani rozumně distribuovat.
Ano, open source negarantuje nic z pohledu bezpečnosti (je špatně to tvrdit), ale dává ti otevřené dveře si nad tím tu bezpečnost postavit a ověřit si jí, vybrat si tu stranou, které budeš věřit. Zatímco u closed source ti zbývá jen ta důvěra v jednu stranu.
"Vždyť v článku je jasně napsáno, že ve zdrojovém kódu ten malware vůbec není"
Ehm.. ve zdrojovem kodu samozrejme je a byt musi, jak jinak by asi vznikla binarka. Problem je uplne jinde, publikovany zdrojovy kod neodpovida publikovane binarce.
Coz je neco, co obecne nema zadne reseni. Protoze dokazat, ze binarka a zdrojak si odpovidaji se nijak obecne neda, dokonce ani rekomplaci ne, protoze ta binarka bude typicky jina pri kazde kompilaci ze? Staci k tomu velmi malo.
Pokud si pamatuju, tak na to tema i tady nejaky ten clanek je, a zajistit, ze z konkretnich zdrojaku vypadne vzdy exaktne stejna binarka vyzaduje spoustu prace a velmi obsahlou dokumentaci na tema nastaveni prostredi.
nikoliv, binárku ti umím napsat i přímo ve strojovém kódu, kdysi jsme tak některé části také sestavovali po instrukcích.
Tady je ale asi myšleno, ve zdrojovém kódu samotného balíčku a ne někde u autora toho malware, že?
Ano, dá se dokázat, že binárka a zdroj si odpovídají, hledej "reproducible builds", to je tahounem poslední doby a kódy se tomu uzpůsobují. Jiná cesta asi nebude, problém nakažených binárek se zvětšuje.
Třeba takový nixos je celý postavený nad tím, že každé opakované volání má shodný výsledek, dostupných balíčků v něm je už ke sto tisícům vč. spousty python balíčků a teď nově se otevírá i spolupráce s php
https://phpconference.com/web-development/leveraging-nix-php-ecosystem/ a slidy tady https://github.com/drupol/ipc2023/releases/tag/v23-79efbb4c24ab0d42c73906d16233a79d9659c5ca)
openSUSE pokračuje ve svém tažení, https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/VWWVEPYEUBBMZN6K7VGUU5KKC7CBSSM2/, 87 % balíčků mají reproducible build.
Debian už pokořil hranici 90 % na většině platformách, https://tests.reproducible-builds.org/debian/reproducible.html
Kdyby to někoho zajímalo, tak na sledování změn v pypi používáme diffoscope.org, teď nově je i oficiálně "stable" na pypi repositáře. Mám chuť na to už nějakou dobu napsat článek a téma více osvětlit, třeba mě tohle donutí se tomu věnovat.