O víkendu probíhá v Praze na Karlově náměstí 13 konference Installfest 2026. Na programu je celá řada zajímavých přednášek a workshopů. Vstup na konferenci je zcela zdarma, bez nutnosti registrace. Přednášky lze sledovat i online na YouTube.
Mozilla a společnost Mila oznámily strategické partnerství za účelem rozvoje open source a suverénní AI. Cílem je ukázat, že open source AI může konkurovat uzavřeným systémům. Obě organizace chtějí posílit technologickou suverenitu a snížit závislost na hrstce velkých technologických firem.
Adam Rice předvedl, že pomocí DNS lze distribuovat a spustit kompletní hru DOOM. Rozdělil WAD soubory a binárky do téměř 2000 DNS záznamů v Cloudflare zóně (jeden TXT záznam v DNS může nést okolo 2000 znaků textu). Ty pak stáhl PowerShellem, dekomprimoval a spustil přímo v paměti počítače bez nutnosti zápisu na disk, což prakticky dokazuje, že DNS může sloužit jako distribuované úložiště dat a možný kanál pro načítání kódu. Repozitář projektu je na GitHubu.
Dnes a zítra probíhají Arduino Days 2026. Na programu je řada zajímavých přednášek. Sledovat je lze od 17:00 na YouTube. Zúčastnit se lze i lokálních akcí. Dnes v Poličce v městské knihovně a zítra v Praze na Matfyzu.
Byla vydána beta verze Ubuntu 26.04 LTS s kódovým názvem Resolute Raccoon. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 26.04 LTS mělo vyjít 23. dubna 2026.
Byla vydána aktualizována Příručka pro začínající wikipedisty a wikipedistky (pdf).
Ubuntu plánuje v budoucích verzích nahradit tradiční nástroje pro synchronizaci času (chrony, linuxptp a gpsd) novým, v Rustu napsaným ntpd-rs, který nabídne vyšší bezpečnost a stabilitu.
Byla vydána nová verze 7.6 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Správce hesel KeePassXC byl nahrazen správcem hesel GNOME Secrets. Bitcoinová peněženka Electrum byla povýšena na verzi 4.7.0. Tor Browser byl povýšen na verzi 15.0.8. Další novinky v příslušném seznamu.
Chris Down v obsáhlém článku „vyvrací mýty o zswap a zram“, vysvětluje, co vlastně dělají a jaké jsou mezi nimi rozdíly. Doporučuje vyhýbat se zram na serveru a bez OOM.
Porota v Los Angeles shledala firmy Google a Meta odpovědnými v přelomovém soudním sporu, který se týká závislosti na sociálních sítích; firmy musí zaplatit odškodné tři miliony dolarů (63,4 milionu Kč). Společnosti, které s verdiktem nesouhlasí, čelily obvinění, že své sociální sítě a platformy záměrně navrhly tak, aby si na nich děti vypěstovaly závislost. Porota došla k závěru, že technologické společnosti při navrhování a
… více »Jádro je 2.6.36 je venku, vydáno bylo 20. října, přičemž od předverze 2.6.36-rc8 došlo jenom k málo změnám. Mezi hlavní vlastnosti této verze patří bezpečnostní modul AppArmor, subsystém pro infračervené ovladače LIRC a nová architektura Tile. Na poslední chvíli byl vypnut mechanismus fanotify sloužící aplikacím pro boj s malwarem; objevily se záležitosti týkající se ABI. Spoustu informací naleznete na stránce o 2.6.36 na KernelNewbies.
Linus také poznamenal, že dva týdny dlouhé začleňovací okno, které začne 21. října, by kolidovalo s jaderným summitem.
(Vývojový cyklus 2.6.36 trval 80 dní, což je shodou okolností téměř přesný průměr za posledních několik let.)
Předtím bylo 15. října vydáno 2.6.36-rc8. Opravdu to dělám nerad a raději bych prostě vydal 2.6.36, ale místo toho vydávám ještě poslední -rc. Je tu (a v nevyřízených mailech) příliš mnoho ruchu, ze kterého nejsem šťastný, a i když jsem si nejprve myslel, že vydání jenom o den nebo dva zpozdím, teď už to vypadá na celý týden, takže proto další -rc.
Stabilní aktualizace: během uplynulého týdne žádné nevyšly.
-- Al Viro
napsal Jonathan Corbet, 20. října 2010
Sada patchů pro škálovatelnost VFS Nicka Piggina je ve vývoji již více než rok. Některé kousky byly začleněny do 2.6.36, ale složitější části byly odloženy, protože si Nick myslel, že potřebují ještě více práce a testování. Pak věci utichly, Nick změnil zaměstnání a jel na dovolenou, takže po nějaký čas se moc nedělo. Nakonec bylo jasné, že Nick pravděpodobně nestihne do začleňovacího okna 2.6.37 patche dokončit.
Proto se David Chinner rozhodl vložit se do toho sám a na těchto patchích zapracovat; konkrétně se věnoval kódu, který rozbíjí zámek inodů na menší části. Jeho první sada patchů byla zaslána koncem září, od té doby následovalo mnoho revizí. Dave pracoval na rozdělení série patchů do menších a snáze revidovatelných kousků. Také vyjmul některé (pro něj) děsivější změny. Následné revize přivedly větší změny, ve verzi 5 se dočteme:
Podle Davea tato sada patchů pomáhá při problémech se škálovatelností, které pozoroval, a i další revidovatelé podle všeho mají názor, že patche začínají vypadat poměrně dobře.
Pak se ale vrátil Nick. I když uvítal nový zájem o práci na škálovatelnosti, netrvalo dlouho a naznačil, že ho nepotěšil směr, kterým Dave jeho patche posunul. Zaslal sérii patchů o 35 částech, o které doufá, že ji začlení; v daném mailu také rozvádí, proč se mu nelíbí Daveův alternativní přístup. Následující diskuze byla občas poněkud drsná, ale většinou se držela technických záležitostí.
Na co nedošlo, byl její závěr. K dispozici jsou dvě sady patchů; obě se týkají průniku vrstvy virtuálního souborového systému a kódu správy paměti. Většina neshod se podle všeho týká toho, jestli by poslední slovo měli mít „lidé od VFS“ nebo „lidé od správy paměti“. Vzhledem ke složité povaze obou sad patchů a blížícímu se otevření začleňovacího okna 2.6.37 se zdá poměrně jasné, že začleněna nebude ani jedna, pokud se Linus nerozhodne, že jednu vybere sám. Odložení tohoto kódu do 2.6.38 poskytne příležitost, aby byly patche důkladně prodiskutovány; možná je bude možné probrat i na nadcházejícím Jaderném summitu.
napsal Jonathan Corbet, 20. října 2010
David Chinner si nedávno všiml problému na jednom ze strojů na kernel.org: slab cache používala více než 2GB paměti, většinu z toho na uzly radix stromu. To ho zaujalo a na problém se podíval blíže; ukázalo se, že na vině je bezpečnostní kód architektury pro ověřování integrity (integrity measurement architecture, IMA), který používá hardwarový TPM a pomáhá tak hlídat, že se soubory v systému se nemanipulovalo. IMA podle všeho používala radix strom, do kterého se ukládaly informace o integritě indexované podle adres inodů. Radix stromy se chovají mizerně, když obsahují řídké klíče, takže IMA způsobovalo vytváření samostatných uzlů pro každý inode v systému. Nasčítalo se to na spoustu paměti.
Z tohoto odhalení vzešlo mnoho otázek včetně následujících:
Odpověď na první otázku je podle všeho to, že když vývojáři IMA začleňovali kód do hlavní řady, nebylo jim povoleno rozšířit strukturu inodu. Proto vytvořili samostatný strom pro ukládání informací o jednotlivých inodech; stalo se, že si vybrali špatný strom a nikdy si nevšimli, jak špatně se choval.
Otázka č. 2 je zodpovězena takto: kód IMA potřebuje neustále sledovat to, které soubory jsou otevřeny pro zápis. Nemá cenu kontrolovat integritu souborů (v podstatě to znamená počítání kontrolních součtů), když je možné je kdykoliv změnit. Bez nepřetržitého sledování souborů IMA nikdy nemůže vědět, které soubory byly otevřeny po zápis, než se nastartovala. Jediný způsob, jak lze mít jistotu, je podle všeho sledování všech souborů od nabootování pro případ, že někdo bude chtít IMA v nějakém okamžiku zapnout.
Co se č. 3 týče, kernel.org používá jádro z Fedory a lidi z Fedory tuto vlastnost zapnuli, protože to vypadalo, že by mohla být pro někoho užitečná. Nikdo neočekával, že bude mít takové dopady na ty, kdo ji nepoužívají. Někteří diskutéři správcům jádra ve Fedoře vytkli, že kód nebyl prověřen před zapnutím, ale prověřit takto bedlivě všechno v jádře je příliš velký úkol na to, aby se dalo očekávat, že se ho Fedora ujme.
Eric Paris začal pracovat na zeštíhlení IMA; jeho patch funguje tak, že čítače „otevřeno pro zápis“ přesouvá přímo do struktury inode, takže většinou není potřeba alokovat samostatné IMA struktury. IMA také začala používat červeno–černé stromy tam, kde tyto struktury potřebuje sledovat. Tato práce odstraňuje většinu plýtvání pamětí za cenu toho, že se struktura inode trochu zvětšuje. To úplně všem nesedlo, obzvláště těm vývojářům, kteří mají pocit, že by IMA vůbec nemělo existovat. Je to ale krok správným směrem, takže lze očekávat, že něco na daný způsob bude začleněno do 2.6.37.
napsal Jonathan Corbet, 19. října 2010
Rychlé prohledání CVE databáze ukáže za tento rok 80 CVE čísel spojených s chybami v jádře. Na jedné z nedávných konferencích se autor tohoto článku svěřil významnému vývojáři jádra, že toto číslo považuje za znepokojivě vysoké. V době, kdy zjevně narůstá komerční, kriminální i vládní snaha o to zneužít bezpečnostní slabiny, by bylo dobré se hodně snažit vyhnout se zatahování nových. Mohli bychom ale dělat více, než děláme teď? Odpovědí, které se autorovi článku dostalo, je to, že v podstatě většina odhalených chyb byly prastaré záležitosti, které byly odhaleny novými nástroji pro statickou analýzu. Jinými slovy opravujeme bezpečnostní problémy rychleji, než je vytváříme.
Toto tvrzení potřebuje ověřit; ověřit ho musí někdo, kdo je dostatečně odhodlán a je dostatečně odolný vůči frustraci. Autor se rozhodl, že to zkusí. „Všechno“, co je zapotřebí, je koneckonců jenom podívat se na každou slabinu a zjistit, kdy byla zavlečena. Jak těžké to může být?
Základní postup tedy byl: vybrat CVE záznam, najít patch, který díru opravil, a pak se prohrabat historií repozitáře a dalšími zdroji a zkusit zjistit, kdy byl problém do jádra poprvé zavlečen. V některých případech bylo relativně snadné najít odpověď; jiné byly dost složité na to, aby to autor nakonec vzdal. Ukázalo se, že jedním z obzvláště cenných zdrojů je bugzilla Red Hatu; vývojáři (hlavně Eugene Teo) tam důsledně pracují na dokumentaci detailů bezpečnostních slabin. Někdy dokonce commit, který chybu zavlekl, byl v daném záznamu jednoduše zmíněn. Pro tento druh výzkumu je užitečná i utilita „git gui blame“.
Takto bylo prozkoumáno přibližně 60 z 80 chyb, pak autor článku definitivně obrátil oči v sloup. Výsledky lze vidět v následující tabulce. Je třeba říci, že v datech níže nevyhnutelně budou nějaké chyby; nejpravděpodobnější chybou bude obvinění commitu, který slabinu ve skutečnosti pouze přesunul z jiného místa. To může vést k posunu, kdy budou slabiny vypadat mladší, než ve skutečnosti jsou. Snaha tu byla, data by neměla být chybná nijak významně.
Další poznámky týkající se tabulky:
Nedošlo k žádnému pokusu najít původce slabin, které byly přítomny již v commitu, jenž zahájil éru gitu během vývojového cyklu 2.6.12. O všem, co tam již bylo tou dobou, lze bezpečně říci, že je to stará chyba.
Některé části kódu se měnily tak často, že by bylo opravdu těžké zjistit, kdy byla slabina zavedena; taková místa autor označil jako „neznámo“. Správnou odpověď by pravděpodobně bylo možné určit dělením půlením [bisecting] a testováním exploitů, ale odhodlání autora nebylo tak silné.
Některé z těchto chyb jsou staré jiným způsobem – CVE-2010-1188 bylo opraveno roku 2008, ale až roku 2010 se zjistilo, že se jednalo o bezpečnostní chybu. Každý, kdo používá aktuální jádro, je v bezpečí, ale takové chyby snadno po dlouhou dobu zůstávají v enterprise jádrech.
Pohled na to, kdy byly slabiny zavedeny, ukazuje následující tabulka:
![[Bezpečnostní slabiny v jádře]](http://www.lwn.net/images/2010/kernel-vulnerabilities.png)
V jistém smyslu měl tedy výše zmíněný hacker jádra pravdu – spousta slabin opravených v uplynulém roce je z doby před érou gitu a jsou tedy více než pět let staré. Zdá se, že bezpečnostní chyby mohou v jádře číhat velmi dlouho, než o ně někdo zakopne – nebo přinejmenším, než je někdo nahlásí.
Podle informací uvedených výše jsme od 2.6.33 opravili tucty slabin, aniž bychom nějakou zavlekli. Platnost druhé části tohoto tvrzení nicméně pravděpodobně nevydrží dlouho – v cyklu 2.6.35 bylo opraveno (přinejmenším) 13 slabin, v 2.6.36 to bylo 21. Můžeme doufat, že jsme jich ve stejné době přidali méně; je nicméně jisté, že 1) jejich počet nebude nulový a 2) pravděpodobně nám bude trvat pět nebo více let, než si jich všimneme.
Může nás trochu utěšit, že velká část známých bezpečnostních chyb z roku 2010 není důsledkem vývoje z roku 2010. Ve skutečnosti, když budeme předpokládat, že některé z chyb jsou ještě starší, můžeme také tvrdit, že nejsou důsledkem „nového“ modelu vývoje jádra, který byl přijat v prvních dnech 2.6. Toto tvrzení by bylo možné ověřit výzkumem dat z éry BitKeeperu; to je ale úkol do budoucna.
Autor článku má nicméně nadále obavy z toho, že je příliš jednoduché vložit do jádra nebezpečný kód a je příliš těžké odhalit slabiny, které byly vytvořeny. Analytické nástroje mohou pomoci, ale když dojde na to udržet slabiny mimo jádro, rozhodně nejsou náhradou pro nudné a únavné revize kódu. Čas od času je zjevné, že revidování není natolik intenzivní, jak by mělo být. Snadno může přijít den, kdy si budeme přát, abychom bývali byli opatrnější.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
netbsd a openbsd maju podobne resp. nizsie pocty (ako freebsd). je vsak pravda, ze maju hodne mensi pocet riadkov ako linux.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz