Byla vydána nová verze 10.0 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Vypíchnout lze nové balíčky ownCloud Infinite Scale a Uptime-Kuma.
Byla vydána nová verze 3.0.8 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Microsoft poskytl FBI uživatelské šifrovací klíče svého nástroje BitLocker, nutné pro odemčení dat uložených na discích třech počítačů zabavených v rámci federálního vyšetřování. Tento krok je prvním známým případem, kdy Microsoft poskytl klíče BitLockeru orgánům činným v trestním řízení. BitLocker je nástroj pro šifrování celého disku, který je ve Windows defaultně zapnutý. Tato technologie by správně měla bránit komukoli kromě
… více »Spotify prostřednictvím svého FOSS fondu rozdělilo 70 000 eur mezi tři open source projekty: FFmpeg obdržel 30 000 eur, Mock Service Worker (MSW) obdržel 15 000 eur a Xiph.Org Foundation obdržela 25 000 eur.
Nazdar! je open source počítačová hra běžící také na Linuxu. Zdrojové kódy jsou k dispozici na GitHubu. Autorem je Michal Škoula.
Po více než třech letech od vydání verze 1.4.0 byla vydána nová verze 1.5.0 správce balíčků GNU Guix a na něm postavené stejnojmenné distribuci GNU Guix. S init systémem a správcem služeb GNU Shepherd. S experimentální podporou jádra GNU Hurd. Na vývoji se podílelo 744 vývojářů. Přibylo 12 525 nových balíčků. Jejich aktuální počet je 30 011. Aktualizována byla také dokumentace.
Na adrese gravit.huan.cz se objevila prezentace minimalistického redakčního systému GravIT. CMS je napsaný ve FastAPI a charakterizuje se především rychlým načítáním a jednoduchým ukládáním obsahu do textových souborů se syntaxí Markdown a YAML místo klasické databáze. GravIT cílí na uživatele, kteří preferují CMS s nízkými nároky, snadným verzováním (např. přes Git) a možností jednoduchého rozšiřování pomocí modulů. Redakční
… více »Tým Qwen (Alibaba Cloud) uvolnil jako open-source své modely Qwen3‑TTS pro převádění textu na řeč. Sada obsahuje modely VoiceDesign (tvorba hlasu dle popisu), CustomVoice (stylizace) a Base (klonování hlasu). Modely podporují syntézu deseti různých jazyků (čeština a slovenština chybí). Stránka projektu na GitHubu, natrénované modely jsou dostupné na Hugging Face. Distribuováno pod licencí Apache‑2.0.
Svobodný citační manažer Zotero (Wikipedie, GitHub) byl vydán v nové major verzi 8. Přehled novinek v příspěvku na blogu.
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