Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
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