Vlákno názorů k článku Svět jednohlavičkových knihoven pro jazyky C a C++ od cc - Zrovna ty STB knihovny jsou plné CVE a...
-
Zrovna ty STB knihovny jsou plné CVE a autor s tím nechce nic dělat. Jsou nebezpečné a dostalo se to i do knihoven jako SDL.
Mi to přijde ujeté. Nechci se naučit tooling, tak vytvořím jeden soubor co má tisíce řádků, nikdo se v tom nevyzná a je tam chyb jako máku. Pořádně testovat radši ne, protože by to znamenalo vytvořit další soubor... No a sám autor na to odpoví, že STB image je jen pro obrázky, které máš pod kontrolou a nejsou malformed...
-
> No a sám autor na to odpoví, že STB image je jen pro obrázky, které máš pod kontrolou a nejsou malformed...
To je pravda. Ale co je na tom špatného?
> Nechci se naučit tooling
Osobně mi nástroje pro buildění C/C++ typu cmake nebo configure + make přijdou strašlivé. Raději si píšu dva skripty, bat soubor pro build na Windows a sh soubor pro build na Macu či Linuxu. Aspoň na první pohled z toho skriptu vidím, jaké flagy jsem předal kompilátoru.
-
panikaStříbrný podporovateljeste o kus dal jde nob.h ktery ke kompilovani Ccka pouziva Ccko :)
a hadejco single header :))
https://github.com/tsoding/nob.h -
Špatné je na tom to, že ty STB knihovny používají jiné projekty, jejichž autoři to třeba ani netuší, popřípadě to jsou závislosti dalších projektů, takže konečný uživatel je vystavený nebezpečí a vůbec o tom neví.
Nechápu, že o tom vůbec musí být diskuze - out of bounds access je špatně a když to autor neřeší, tak to hodně vypovídá o tom projektu.
Build system je téma na jinou diskuzi. Vím ale, že bez third party knihoven dnes nic udělat nejde, a cmake (ačkoliv ten scripting language je hrůzný) je zatím to nejvíc funkční řešení, které jsem používal.
-
> Nechápu, že o tom vůbec musí být diskuze - out of bounds access je špatně a když to autor neřeší, tak to hodně vypovídá o tom projektu.
Já myslím, že diskuze efektivně skončila. Autor jednoznačně specifikoval preconditiony. Komu se to nelíbí, musí ty obrázky zkontrolovat sám, nebo použít jinou knihovnu. A ke konečnému uživateli se to může dostat jen přes nepřerušený řetěz knihoven, jejichž autoři řeší bezpečnost +- stejně.
Nemusí se nám to líbit, ale takhle se v C řeší složité problémy odnepaměti. Nedefinované chování, IFNDR, démoni z nosa a tak dále.
-
A k těm build systémům...
IMO nejspolehlivější cesta, jak dotlačit lidi k nebezpečnému chování, je naházet na bezpečnou cestu dost klacků pod nohy. Lidi chcou udělat svou práci s minimem dodatečného opruzu. Cokoliv jim zavazí, budou mít tendenci obcházet.
To, že nejvíc funkční řešení je příšerný cmake je pak důvod, proč jsou tyhle knihovny tak atraktivní. Máte nějakou srovnatelně jednoduchou knihovnu, co na bezpečnost nedlabe? Sem s ní!
-
Pavel TišnovskýZlatý podporovateljako že když řeknu, že obrázek má 100x100 pixelů, ale to pole bude menší, tak to udělá nějakou neplechu v paměti? (předpokládám, že jen čte). Jako teoreticky někde při aplikaci RLE nebo LZ77 může dojít k přetečení, ale to možná nemáš na mysli?
10. 2. 2026, 21:54 editováno autorem komentáře
-
To je všechno dohromady. Autor vůbec neřeší out of bounds access atd... Já ani nevím kolik těch chyb tam je, protože sám autor to odmítl řešit s tím, že to bylo navržené jen pro obrázky, které jsou v pořádku. Teoreticky cokoliv typu DEFLATE, RLE, atd... může způsobit out of bounds memory access v této knihovně.
Ještě horší je ale stb_truetype - tam se přičítají offsety z dat TTF bez jakékoliv kontroly, takže to je hodně divoké, a je to "by design".
Toto prostě není dobrý software engineering. Ty knihovny jsou špatně navržené...
-
Pavel TišnovskýZlatý podporovatel
já to chápu pro LOADing, ale pro ukládání moc ne - tam jsou všechny obrázky v pořádku by design ne?
-
ani ja sa nechcem učiť tooling, je ich priveľa a všetko sú to komplikované molochy, čas sa dá využiť aj lepšie. Mám rád c++ z nostalgických dôvodov, ale väčšinou robím C#, C++ len na starých projektoch a problémy s tým, ako skompilovať projekt s rôznymi knižnicami rôznych autorov je jeden z dôvodov, prečo by som v c++ nový projekt nezačínal