Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
Byla vydána nová verze 10.8 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyl balíček DietPi WireGuard.
Na vytvoření jednoduchého repozitáře existuje nespočet nástrojů. Pro účely
tohoto článku jsem zvolil reprepro, protože nabízí jednoduché rozhraní a přesto poskytuje velmi mnoho funkcí.
Pro začátek si vytvoříme adresář, kde budeme chtít, aby reprepro pracovalo:
$ mkdir reprepro $ cd reprepro
Dále potřebujeme adresář pro nastavení:
$ mkdir conf
Minimálně musíme říci, jaké distribuce budeme v repozitáři mít, vytvoříme tedy
conf/distributions (tato ukázka obsahuje jenom jednu distribuci, ale můžeme jich použít, kolik jen chceme):
Origin: Stojan Jakotyč Label: Unofficial Packages Suite: unstable Codename: sid Architectures: i386 amd64 source Components: main contrib non-free Description: My playground
Nyní již reprepro můžeme normálně používat. Pokud jsme použili v konfiguraci
distribucí Suite, můžeme si třeba nechat vygenerovat symbolické odkazy na kódová jména:
$ reprepro -b . createsymlinks
Parametr -b určuje cestu k pracovnímu stromu reprepro, v tomto případě je to tedy aktuální adresář. Jak vidíme, reprepro už si nijak nestěžuje, takže můžeme přidat první balíček do repozitáře:
$ reprepro -b . include unstable /tmp/ukolovnik_1.0-4_i386.changes Exporting indices...
Když se nyní podíváme do pracovního adresáře, zjistíme, že se vytvořilo
několik nových adresářů a souborů. Struktura je podobná jako na jakémkoliv
mirroru Debianu - tedy adresář pool obsahuje vlastní balíčky, kdežto dists seznamy balíčků pro dané distribuce. Dále si reprepro vytvoří adresář db, kde jsou uloženy jeho interní informace o repozitáři a balíčcích.
Ručně přidávat balíčky je ale dost práce, tak je určitě lepší tento proces
zautomatizovat. Podporu už pro to reprepro má, stačí mu v souboru
conf/incoming říci, odkud si balíčky brát:
Name: incoming IncomingDir: /tmp/reprepro/incoming TempDir: /tmp/reprepro/tmp Allow: unstable>sid Default: sid
První řádek určuje jméno této fronty, můžeme použít cokoliv. Druhý adresář,
kde se fronta nachází, a třetí místo, kam se mohou odkládat dočasné soubory.
Parametry Allow a Default určují pravidla pro nahrávání balíčků. Zde tedy balíček určený pro unstable skončí v distribuci sid a všechny ostatní také v distribuci sid. Zpracování pak spustíme následujícím příkazem, případně ho můžeme dát do cronu a nechat frontu zpracovávat automaticky:
$ reprepro -b . processincoming incoming Exporting indices... Deleting files no longer referenced...
Pokud Debian používáte již nějakou chvíli, asi víte, že program apt-file umí vyhledávat v seznamech souborů nenainstalovaných balíčků. Aby to ovšem fungovalo, musí být v repozitáři seznam souborů v balíčcích (soubor Contents). Program reprepro umí generovat i tento seznam, stačí zapnout tuto volbu v conf/distributions. Když už budeme v tomto souboru něco měnit, můžeme ještě zapnout bz2 kompresi pro všechny seznamy:
DebIndices: Packages Release . .gz .bz2 DscIndices: Sources Release . .gz .bz2 Contents: . .gz .bz2
Pokud máme pocit, že by se balíček mohl hodit i někomu dalšímu, tak je dobré ho dostat do distribuce. Jakékoliv nové balíčky musejí před přijetím projít frontou nových balíčků, kde čekají na to, až je správce ftp repozitáře zkontrolují a přijmou do distribuce. Po této kontrole už není nahrávání nových verzí omezeno.
Než se však pokusíme dostat náš výtvor do distribuce, měl by být balíček v co
nejlepším stavu, abychom ušetřili práci sobě i dalším lidem, kteří se s
balíčkem budou muset poprat. Pro základní kontrolu poslouží lintian popsaný dříve v seriálu, ale nemalou pozornost bychom měli věnovat také licencím
jednotlivých souborů a jejich popisu v debian/copyright.
Když si myslíme, že máme vše správně, můžeme pokročit k nahrávání. Jako naprostý nováček máme možnost jen si nechat balíček nějakým vývojářem nahrát do distribuce. Tomuto se říká sponzorování a sponzor je zodpovědný za kvalitu balíčku, přestože se o něj stará někdo jiný. Poté, co získáme dostatek zkušeností, je možné se pokusit postoupit na vyšší úroveň a stát se Debian maintanerem, kdy už můžeme nahrávat svoje balíčky samostatně. Další možností k růstu je Debian developer, kdy již můžeme do distribuce nahrávat cokoliv (samozřejmě při dodržování daných pravidel).
Jak již jsem napsal dříve, sponzorování balíčku je zpočátku jediný způsob, jak dostat balíček do distribuce. Nejtěžším úkolem je (hned po vytvoření bezvadného balíčku) nalezení vývojáře, který bude ochotný balíček zkontrolovat a nahrát do distribuce. Pro tento účel nám poslouží server http://mentors.debian.net, kam balíčky pro sponzory můžeme nahrávat, a mailing list debian-mentors, na kterém se pokusíme nalézt sponzora.
Lidí hledajících sponzora pro svůj balíček je hodně a čas vývojářů je omezený, takže je nutné zaujmout a dobře odvést svojí práci. Pokud se snažíme do distribuce dostat stopadesátý editor, tak určitě budeme mít mnohem těžší pozici, než při práci s nějakým zajímavým nástrojem nebo hrou. Snažte se proto při psaní mailu myslet na to, že musíte někoho zaujmout a uvést všechny relevantní informace, které by sponzor mohl potřebovat (na stránkách mentors.debian.net si můžete zkopírovat šablonu, která bude všechny potřebné informace obsahovat).
V prvních balíčcích budou obvykle snadno dohledatelné chyby, takže když má někdo k našemu balíčku připomínky, jedná se většinou o dobře míněné rady; snažte se jimi řídit. Nicméně se nebojte diskutovat o případných alternativních řešeních, nikdo není neomylný. Většina sponzorů má seznam věcí, které kontrolují, jeden z nich je například Checklist for sponsored packages. Občas nebývá od věci si takový seznam projít ještě před předhozením balíčku na mailing list a jeho veřejným pranýřováním :-).
Pokud už se s nějakým sponzorem dohodneme na jednom balíčku, obvykle bývá i přístupnější nahrávání našich dalších balíčků, ale nemusí to být pravidlem.
V současné době je poměrně velká část balíčků spravována v týmech. Jedná se o poměrně snadnou možnost, jak spravovat balíček bez toho, aby se člověk musel stát Debian maintainerem nebo developerem nebo musel složitě shánět sponsora, protože se v týmu snáze najde nějaký Debian developer, který balíček nahraje. Jinak se jedná o stejný případ jako sponzorování.
Pokud už máme za sebou nějakou práci na sponzorovaném balíčku, můžeme zkusit
za tento balíček kompletně převzít zodpovědnost a stát se Debian maintainerem.
Když se jím staneme, můžeme nahrávat svoje balíčky, které sponzor nahraje do
distribuce s nastaveným příznakem DM-Upload-Allowed. Informace o tom, jak se stát Debian maintainerem, najdeme na wiki.debian.org/Maintainers.
Jako Debian developer už můžeme nahrávat do distribuce cokoliv a musíme tedy splnit o něco přísnější podmínky. Nicméně tento postup je jasně definovaný a při troše štěstí není problém ho celý absolvovat během půl roku.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: