Jen dnes uz je problem ty veci tehdy vytvorene na necem pricetne aktualnim vubec pustit... :-) Jazyk ma 30 let... ale ty zmeny jsou obcas divoke.
python 2.7
ruby 1.8
java 7
java 8
Lua 5.1
A asi bych ještě chvilku mohl pokračovat v jazycích a jejich verzích, které vzdorovali svému původnímu osudu.
Jen tim bych se verejne moc nechlubil, pokud vedle obhajuju utahovani sroubu model NUKIB.🤣 Samozrejme, z neceho se jde vylhat skrze analyzu rizik, ale long-term optikou je to jen o zametani problemu pod koberec a nebo tvorbe pakarny pro nastupce, kdyz uz sam striham metr.
Kdyz ten legacy jazyk vypadne z pidporovaneho distra, je to pruser. A holt mnozi k tomu pristupuji systemem "si to nejak doklepu, po me potopa".
pokud prokážeš, že danou verzi udržuješ nebo jí někdo udržuje, ani NÚKIBu to nevadí. Však na tohle téma jsem s ními už i seděl.
Podporované distro je chiméra. Stejně prakticky musíš legacy věci provozovat bokem, kompilovat si sám a zajistit si, že ti to běží na aktuální distribuce, jinak opravdu můžeš mít problém s NÚKIBem.
Vazne bych chtel videt tu bezpecnostne poctive opatchovanou Javu7, Python 2.7 ci PHP5.3 - kdyz na to upstream davno dlabe. To, ze to jen prekompiluju na novy distro vubec nic neresi. A silne pochybuju, ze i NUKIB ma kapacity na to, aby tohle poctive overil - proste se vezme nejake tvrzeni na papire a tim to cele skonci. Ale ano, pekny cirkus na koleckach si tu budujeme ;-)
NÚKIB to ověřuje papírově, tj. kouká, jestli sleduješ a hledáš zranitelnosti, jestli máš proces jak zranitelnosti řešíš, jestli je někdo, kdo zdrojový kód umí upravit a máš s nim nějaký vztah atd. Není jeho role, aby ověřoval zdrojové kódy a nastavení systému.
Java 7 se používá na železnici, a ano patchuje se to, odstraňují se části, které jsou problematické, izoluje se celý proces, berou se tomu ty a ty oprávnění. Zamezit zranitelnosti nemusíš jen tak, že aktualizaci na verzi, kde je vyřešená, ale můžeš udělat i jiné opatření. Někdy se to bohužel zkracuje jen na kontrolu verze.
Python 2.7 třeba používá ESA a tam je několik společností, který jí k tomu zajišťují podporu.
Samozřejmě jsou to okrajové případy a stojí to dost peněz, ale i taková varianta je v případě NÚKIBu možná, diskutovali jsme to s nimi. Sám NÚKIB to musí vědět dobře, však si sám provozuje několik EOL nástrojů...
udržování a portování starého kódu v open source, unix, linuxu, bsd funguje odjakživa.
Schválně si všimni v jak starém kódu jsou objevovány zranitelnosti. Čím novější, tím toho je víc. Stejně tak pokud se objeví velmi letitá zranitelnost, můžeš si jí ve svém forku také sám vyřešit.
Hon za co nejčerstvějšími verzemi paradoxně reálnou bezpečnost snižuje. Letitý a udržovaný kód může mít v tomhle výhodu. Nové funkce a rozhraní jsou vždy velký potenciální problém.
Python 2.7 třeba pořád udržuje Stuart Henderson z openBSD, které python 2.7 podporuje i v aktuální 7.7 verzi.
To, že původní vývojáři kód opustí a uzavřou neznamená, že ho nebude jiná parta udržovat. A to jestli byla stará parta lepší než ta nová, je vždy na individuálním posouzení, nelze to z toho odvozovat.
To stejné v php, ona tam je také spousta zranitelností v doplňkových modulech a nikoliv v samotném interpretu nebo jazyku.
Dnes a denně zažívám bojem, kdy různé auditní nástroje reportují zranitelnosti v RHEL balíčkách, které ale Redhat udržuje, opravuje a patchuje, opět to dělá bez ohledu jestli původní projekt žije nebo nikoliv. Dělá to po dobu podpory, kterou prodal. To je naprosto stejný mechanismus. Považuješ kvůli tomu RHEL za nebezpečnou distribuci stejně jako spousta skenovacích nástrojů?
Na ten stary kod se cilene hlavne uz nikdo moc "formalne" nezameruje - takze samozrejme okometricky to vypada "cisty". Ne v tom duchu, ze by se vubec reportovaly zranitelnosti u systemu, ktere jsou EOL. A neni to jen specifikum opensource, takhle funguji i vetsina closed-source vendoru.
A ze by zrovna konkretne NUKIB vecne fnukajici na personalni poddimenzovanost mel dost lidi na tohle si fakt nemyslim. Ale jestli nam doda PHP5.3 na kterou da ouredni bumazku, ze je "safe", tak mu vsichni zulibaji ruce, zeano...
to co se veřejně reportuje může být jen malá část objevených a opravených zranitelností. Některé se mohou opravit i neúmyslně. Nástrojů a možností jak odhalit dnes chyby je daleko více než tomu bylo v minulosti.
Už třeba jen kolik potenciálních zranitelností se opravilo migrování C kódu na arm architekturu, všechny ty ochcávky s pointery a inty se musely konečně napsat pořádně. Pak i arm port může být bezpečnější než původní C kód.
EOL se vždy vztahuje k týmu (firmě, autorovi whatever) a zdrojovému kódu. Někde může být něco EOL a jinde to může být naprosto normálně udržované a funkční. Nemaž ten kontext, v kterém EOL vznikl.
To bylo jen popíchnutí, protože zrovna NÚKIB na to tak trochu kašle, protože kupodivu není ten, kdo musí sám sobě něco reportovat :).
Tím nechci nikoho navádět k neuaktualizování, jen to není jediná cesta, je ale asi zdaleka nejlevnější a nejjednodušší.
Muj denodenni fight s rychlosmaznymi securitaky. Vas scan tool funguje blbe prectete si changelog. Kdyby byly ty reporty aspon nejaky strojove citelny format tak to muzu prohnat pres skript.
Zatim se mi podarilo dostat fight az k vendoroviale tam to hnije ve fronte.
Velky prachy za scan tool ktery ani neumi zjistit jestli je backport instalovan pro danou verzi.
Tohle je ještě ten lepší případ.
Horší je, když ten superdrahý scanovací tool tvrdí, že je instalovaná stará verse, protože se zastaví na záznamech z instalace a neobtěžuje se zjistit, co tam skutečně běží. Pak ještě najde zálohu předchozí verse, která tam zůstává pro rychlý roll-back
, kdyby ta nová náhodou rozbila nějakou utajenou závislost v produkci, a nakonec si usmyslí, že když na nějakém portu probíhá šifrovaná komunikace, které nerozumí, jde určitě o malware - a za vydatné pomoci AI taky přesně napíše, jaký. (Protože všechny normální aplikace přeci komunikují po HTTPS na portu 433 - všechno ostatní je podezřelé!)
AKurat dnes som si hovoril, ze to PHP prezilo ten hype okolo RoR a dnes je Ruby prakticky mrtve, zatial co PHP zije dalej, a to mu pred viac ako desiatimi rokmi Ruby komunita vestila smrt.
12. 6. 2025, 14:10 editováno autorem komentáře
Ruby není mrtvé ani náhodou. Sám jsem z toho překvapen. Neustále narážím na inzeráty hledající Ruby programátory a to u i českých firem. Jen prostě není moc vidět. Uživatelská základna stále roste. Stačí se podívat na statistiky.
TL;DR například každým měsícem roste počet stažených gemů pro RubyGems.org.
4.15B stažení na RubyGems.org vs 2.6B stažení na packagist.org za Duben 2025.
Neříkám že je to nejpopulárnější jazyk, nebo populárnější než PHP na základě těchto jednoduchých měření, ale rozhodně není mrtvý a neupadá v zapomnění.
https://packagist.org/statistics vs https://rubygems.org/stats
Detailnější statisktiky pro RubyGems.org lze vydolovat na https://sql.clickhouse.com/. Přeji příjemnou zábavu.
Tie cisla teda nie su vobec uchvatne. Takisto ani pracovne ponuky v strednej EU. Hlavne dost ludi uslo na NodeJs, a potom z NodeJs na Rust, a ked bude v hype zas dalsi cool jazyk, kde si clovek musi robit vsetko sam, tak pojdu nan (parafrazujem Davida Grudla).
A to isti ludia na Slovensku na tom chceli stavat vsetko vstatnej sprave.
Prenosny Hasici Pristroj stale zije :-) . Me prvni vetsi prgani webovych patlanin po perlu :-). Perl bylo dost peklo BTW. Ale porad lepsi nez vyrabet cgi skripty v necem kde se da na dalku exploitnout system raz dva.
Jo ty cgi skripty v perlu si taky pamatuji. A někde mám ještě i knihu pana Satrapy. Ale docela brzo jsem objevil kouzlo php, hlavně v tom, že se dal kód vkládat přímo do html stránek a nebylo třeba je celé generovat tím perlem, nebo nějak složitě přesměrovávat tam a zpět.
Prave tohle vkladani kodu primo do stranky je podle me nejsilnejsi karta php. Stejne jako javascript.
Kdyz si prochazim xchat.cz, vidim soubory s priponou php. Toz ja nevim. Taky to muze byt legracka od tvurcu a vubec na php nebezi, jak pisete.
Po malých magických BBSkách na pár kb/s spojích, přes aplikační logiku psanou formou modulů pro Apache, CGI scriptech bylo PHPčko (Personal Home Page) příjemná změna. Pro aktualizaci obsahu stačilo např. 10 000x načíst stránku aby se vyčerpal (MaxRequestsPerChild) a server si aktualizoval změněné soubory (vím že to šlo i jinak). Dodneška mám pár programů, které téměř bez změny běží online > 25let. (Hejty ohledně "bezpečnosti" jste si už užili v diskuzi výše.)
Nicméně ty přešlapy ve vývoji někde mezi 2000..2005 mě odehnaly dál, až jsem začal svůj oblíbený Python používat i na webové aplikace a to už mi zůstalo.
ten MaxRequestsPerChild je co si pamatují věc php-fpm, ty jsi ale mohl používat přímo module do apache nebo fcgi, kde se vždy pro každý request četl aktuální soubor.