Názory k článku
Fwupd přechází z XZ na Zstd, kromě důvěry získá také lepší kompresi
-
U malých souborů to je sice pravda, ale to nic nemění na tom, co jsem napsal. A jinak xz lepší pro archivaci... ono si docela rozmyslíte, jestli budete mít s xz 9 o 5 % menší soubor co se bude komprimovat desetkrát pomaleji než zstd 11 když ten soubor má třeba deset GB. Tolik k té archivaci. Zlaté zstd.
-
Pomalejší při kompresi nebo dekompresi? OP píše o dekompresi. U mě (podle hyperfine) trval jeden zstd -d 6.5 ms, zatímco xz -d 32 ms.
Co se velikosti týče, zřejmě ve srovnání nepoužili xz --extreme, který má své mouchy (není deterministický a někdy paradoxně zvětší výsledný soubor). Ale i s ním mi vychází zstd o pár % lépe,
664Ki firmware.xml.xz
652Ki firmware.xml.zst(testováno s dnešním fwupd firmware.xml).
3. 4. 2024, 19:07 editováno autorem komentáře
-
[Jakub Štech]
Ja osobne pouzivam xz (lzma) na tvoru samospustitelnych archivu (vyuzivam je na automaticke spousteni, konfiguraci a spravu dat hlavne pro hry spooustene pod dosboxem a vyjmecne i ve wine). Lzma zabere sice vyce casu pro komporesy, ale dekomprese je pomerne hodne rychla. Navic ma docela slusny kompresni vykon. To vsechno beru jako rozumne vlastnosti a cenu pro moje potreby.
Pod vlivem jednoho z clanku zrovna tady na rootu jsem otestoval i vyuziti Zstd ( konkretne se jednalo o slavny Duke Nukem 3D Atomic Edition) a jako nadseni zadny. Pomerne mnoho casu jak na kompresy, tak i na dekompresy a vysledny balik nebyl ani nijak moc vyzname mensi nez s xz. Dalsi velky problem bylo hlidani si specifickych argumentu, ktere bylo nutno pri maximalni kompresy zadat Zstd pro dekompresy archivu (coz vedlo k vetsi slozitosti dekompresniho skriptu oproti predchozim variantam a nutnosti ukladat specificke zaznami o kompresnich paramtrech, nebo s nimi generovat dekompresni skript. Proste o rad vyssi komplexita. nic co by se mi libilo)
Takze jsem nakonec vyhodnotil (prozatim), ze mi Zstd za tu namahu nestoji. Aneb jak by se kulatne napisalo ve vedeckych kruzich: "Vyhody Zstd se mi nepodarilo prokazat. Je potreba dalsiho vyzkumu..."
6. 4. 2024, 13:15 editováno autorem komentáře
-
Tady bych si také dovolil poznamenat, že panika kolem xz jako takového není zcela na místě.
1. xz mělo smůlu/štěstí, že se to čirou shodou náhod provalilo. Kolik dalších esenciálních utilit nebo knihoven je úspěšně kompromitováno, ať už stejným útočníkem, nebo i jiným, můžeme jen hádat. Bezpochyby je na podobné backdoory enormní poptávka jak ze strany státních aktérů, tak i těch větších z podsvětí.
2. xz je nyní nejen pod všemi symbolickými lampami, ale i pod značnou částí symbolických mikroskopů. Dalo by se říci, že to zanedlouho bude jeden z nejlépe auditovaných kusů kódu v opensource světě.
-
>> Dalo by se říci, že to zanedlouho bude jeden z nejlépe auditovaných kusů kódu v opensource světě
A nebo naopak, XZ hlavní hráči opustí. XZ má víc problémů než jen ten poslední backdoor, viz https://www.nongnu.org/lzip/xz_inadequate.html
-
Takže vlastně přidali další vektor útoku :-D ?
Já jsem čekal, až toto začnou některé projekty dělat, ale podle mě to nedává smysl. xz není možné ze systémů dostat teď hned pryč, takže je úplně jedno, že nějaký projekt přidá další knihovnu pro kompresi. xz potřebuje hlavně audit - pak to bude možná paradoxně nejbezpečnější formát :)
-
To nebude nikdy, je to komplexní moloch se širokou nabídkou děr a návrhových chyb. https://www.nongnu.org/lzip/xz_inadequate.html
-
Disclosure statement: The author is also author of the lzip format.
Autor určitě chtěl říct, že lzip, o kterém sice nikdo neslyšel a nikdo ho nepoužívá, je mnohem lepší :)
Má ale smůlu... xz je ten formát, který se používá pro distribuci všeho možného, a proto se taky stal terčem toho útoku. Já se xz teda nechci zastávat, je mi úplně jedno jaký algoritmus se pro kompresi používá, ale prostě najednou ho přestat používat nejde, a to by měl pochopit každý... takže buď pořádný audit a nebo reimplementace.
ČLÁNKY DO MAILU