Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Současné vývojové jádro 2.6 je 2.6.27-rc6 vydané 9. září. Pořád to samé - kromě toho, že od -rc5 uplynuly téměř dva týdny. Diff je ale přibližně stejně velký, takže hádám, že to znamená, že věci se zklidňují. Všechny detaily lze nalézt v kompletním changelogu.
V době psaní tohoto článku nebyly do repozitáře hlavní řady od vydání 2.6.27-rc6 začleněny žádné patche.
Současné stabilní jádro 2.6 je 2.6.26.5 vydané 7. září. Obsahuje jedinou opravu chyby při překladu zavedenou jádrem 2.6.26.4, které bylo vydáno dříve toho dne. 2.6.26.4 obsahuje poměrně dlouhý seznam oprav chyb.
7. bylo vydáno i 2.6.25.17, které také obsahuje poměrně mnoho oprav.
Starší jádra: proces 2.4 začal znova vydáním 2.4.36.7, které opravuje "několik menších bezpečnostních záležitostí" a pár dalších problémů. Venku je také 2.4.37-rc1; obsahuje mnoho vylepšení; detaily vizte v oznámení.
Je tu patronát. To je příklad, kde řekněme korunní princ Bavorska dá Linusu Torvaldsovi zámek a vodní příkop a pobídne ho, aby napsal kód pro potěchu dvora, jinak bude vržen do sklepení mezi ty BSD psy. Linus vytvoří skvělé dílo bohatě zdobené sadou zpráv po přihlášení, které chválí jeho ctěného patrona, aby později zemřel v bídě poté, co do jaderného ovladače zahrnul nějaké pohrdavé komentáře o lvici milenky generálního ředitele OSDN.
Kritici patronátu poukazují na to, že žít podle vrtochů vzdálené a sebestředné elity je pro linuxového programátora ponižující život, připomínající jak středověkou robotu, tak bytí pouhým uživatelem Linuxu, což jsou oboje strašlivé epochy, o kterých si jako civilizace přestavujeme, že jsme je překonali.
-- Danny O'Brien (recyklovaný sloupek, ale pobaví i tak)
V Ubuntu obecně upstream považujeme za "svoji SKÁLU", čímž máme na mysli, že chceme, aby byl upstream spokojen se způsobem, jakým vyjadřujeme jejich nápady a jejich práci. Víc než spokojen - chceme, aby byl potěšen! Většinu naší snahy zaměřujeme na integraci. Naši konkurenti to vykládají jako "Canonical nepřispívá", ale mnohem přesnější je říci, že své přispívání měříme v efektivnosti toho, jak dostaneme nejnovější stabilní práci z upstreamu s bezpečnostními aktualizacemi co nejširšímu publiku, aby ji mohlo testovat a milovat. Podle mě je to velký příspěvek.
Grr. Rád bych řekl "Já vám to říkal" a sepsal další kázání na téma patche z -rc série. Jenže jsem příliš líný, takže lidi - prosím, domyslete si sem mé standardní kázání.
Nevěděl jsem, že je poslání testovacího patche, který nepochybně není příliš hezký, dneska hrdelní zločin.
V budoucnu se budu držet zpátky a na takové věci se budu dívat pouze od pondělí do pátku mezi devátou ranní a pátou odpolední hodinou a posílat testovací/RFC patche budu, jenom pokud je schválí komise "není to sračka" [nonshitapproval committee], která se schází jednou za měsíc.
Jaderný summit 2005 zahrnoval diskuzi na opakovaně se objevující téma: jak může komunita vytvářet jádra s méně chybami? Jedním z problémů, který byl na daném sezení identifikován, bylo začleňování významných změn pozdě ve vývojovém cyklu s tím výsledkem, že není dost času pro testování a opravy chyb. Jako reakci účastníci summitu navrhli koncept "začleňovacího okna", čtrnáctidenního období, ve kterém se do hlavní řady začlení všechny významné změny pro daný vývojový cyklus. Jakmile se začleňovací okno zavře, vítány budou pouze opravy chyb.
O tři roky později je začleňovací okno dobře zavedeným mechanismem. Během dané doby disciplína spojená se začleňovacím zesílila; nyní je poměrně neobvyklé, když se do hlavní řady dostane významná změna mimo začleňovací okno. Jediná výjimka, kterou se hodí zmínit, je začleňování nových ovladačů později v cyklu, což je založeno na tvrzení, že ovladač, což je kompletně nová a celistvá funkce, nemůže způsobit regrese. I tak jsou tu rizika: ovladač pro webkamery UVC, který byl začleněn poměrně pozdě v cyklu 2.6.26 (v 2.6.26-rc9), s sebou zavlekl bezpečnostní díru.
Pravidlo začleňovacího okna je často vyjadřováno jako "po vydání -rc1 se dovnitř dostanou pouze opravy". Nedávné diskuze ale objasnily, že se u Linuse začíná rozvíjet poněkud restriktivnější pohled na to, jak by měl probíhat vývoj mimo začleňovací okno. Nadcházející jaderný summit 2008 se na toto téma může podívat a některá pravidla změnit.
V krátkosti se Linus rozhodl, že "pouze opravy" není dostatečně disciplinované; spousta práce, která je charakterizována jako "oprava", může být sama o sobě zdrojem nových regresí. Zde tedy máme, jak by Linus chtěl, aby vývojáři odnynějška pracovali:
Tady je hrubý náčrt:
tak proč mi to lidé posílají?
Není pochyb o tom, že přísnější pravidla mnoho vývojářů překvapila - nicméně, když nic jiného, frekvence toho, jak často je Linus nabručený na zasílatele patchů, věc vyjasňuje.
A v této záležitosti je pravda, že Linus v minulosti nevynucoval takové pravidlo, které je výše. Kromě nových ovladačů změny po začleňovacím okně typicky zahrnovaly věci jako styl kódu a opravování bílých znaků, anotace nástroje sparse a tak dál. Relativně málo z těchto věcí je vybaveno záznamem na seznamu regresí.
Z jiného pohledu je zde tabulka, která se objevila v článku statistik vývoje 2.6.26, aktualizovaná o informace (aktuální) z jádra 2.6.27:
| Vydání | Začleněných sad změn | |
|---|---|---|
| do -rc1 | po -rc1 | |
| 2.6.23 | 4505 | 2570 |
| 2.6.24 | 7132 | 3221 |
| 2.6.25 | 9629 | 3078 |
| 2.6.26 | 7555 | 2577 |
| 2.6.27* | 7733 | 2451 |
* (do 9. září).
Zdá se, že 2.6.27 následuje trend nastavený předchozími jádry: řádově 25 % sad změn z celkového počtu je začleněno mimo nominální začleňovací okno. Nedávné shrnutí regresí 2.6.27 ukazuje během tohoto vývojového cyklu celkem 150 regresí, z nichž 33 nebylo vyřešeno. To naznačuje, že minimálně 2300 patchů začleněných od 2.6.27-rc1 nebyly opravy pro regrese v seznamu.
Politika "pouze opravy regresí" je tedy skutečně nová - a ještě není v platnosti. Pokud by tato politika měla vydržet, mohla by mít několik zajímavých dopadů, včetně, možná, zvýšení počtu oprav pro ne-regrese dodávaných v jádrech od distributorů. Vývojáři by mohli být mnohem horlivější při hlášení regresí, aby s nimi spojená oprava mohla být začleněna. S méně změnami později v cyklu by se vývoj mohl o trochu zkrátit, možná i tak, aby bylo osm týdnů konečně platným cílem. A samozřejmě bychom prostě mohli získat jaderná vydání s méně chybami, na což by se stěžovalo jen obtížně. V blízké době nicméně očekávejme více nabručených e-mailů vývojářům, kteří se stále snaží pracovat podle starších pravidel.
Projekt infračerveného dálkového ovládání pro Linux [Linux Infrared Remote Control project, LIRC] poskytuje ovladače pro mnoho infračervených vysílačů a přijímačů. Pravdědpodobně ho nejvíc využívají lidé, kteří používají MythTV a podobné balíčky; koneckonců, nutnost zvednout se z gauče kvůli změně kanálu by úplně zničila zážitek. Přes svou zavedenou uživatelskou základnu a přestože mnoho distributorů kód dodává, si LIRC ovladače nikdy nenašly cestu do hlavní řady jádra. V současnosti se jejich vývoji a údržbě skoro nikdo nevěnuje; odkaz na "Caldera OpenLinux" na webové stránce projektu to jasně ukazuje.
LIRC je ale užitečný kód a, jak je u ovladačů mimo strom běžné, většina lidí by ho raději viděla v hlavní řadě. Začlenění se o krok přiblížilo 9. září, kdy Jarod Wilson zaslal verzi LIRC ovladačů ke zvážení. Zdá se, že Jarod (společně s Janne Grunauem) na těchto ovladačích pracovali několik měsíců; během toho eliminovali "desítky tisíc" stížností skriptu checkpatch.pl a pročistili mnoho věcí.
I po této práci ale LIRC ovladače zjevně nesplňují běžné standardy jádra. Na některých místech jsou použity velmi podivné konvence kódu. Mnoho ovladačů má rozbité (nebo úplně chybějící) zamykání. Přetékají duplicitním kódem. Jeden ovladač obsahuje implementaci parseru příkazů ve své funkci write(). Další je pro hardware, který již má v hlavní řadě jiný ovladač. A, což je důležité, tyto ovladače nefungují se vstupním [input] subsystémem.
V minulosti Linus Torvalds (a jiní) argumentoval pro začlenění ovladačů tak brzy, jak je to možné. Jestliže je kód ošklivý, šance na jeho zlepšení se značně zvětšují, jakmile je v hlavní řadě a ostatní ho mohou opravit. Zdá se, že LIRC ovladače silně podporují tvrzení, že kód mimo strom je téměř nutně horší kód. Tyto ovladače jsou zde téměř dekádu, distributoři je zahrnují do balíčků a používá je velké množství lidí. Přesto všechny obsahují velké množství vážných problémů, které nebyly nikdy řešeny.
Nyní, když byly ovladače zaslány do linux-kernel, bylo na docela dost těchto problémů poukázáno; Jarod a Janne na revize reagovali a jednotlivé záležitosti opravovali. Filozofie "začlenit ovladače brzy" by hovořila pro zahrnutí LIRC do 2.6.28 i kdyby zůstávaly vážné problémy. Přítomnost v hlavní řadě by kód zviditelnila, což by (doufejme) inspirovalo více vývojářů k tomu, aby ho opravili. Začlenění LIRC by také zbavilo distributory nutnosti vytvářet pro tyto ovladače oddělené balíčky.
Jednu důležitou otázku je však třeba vyřešit předtím, než bude možné o LIRC vážně uvažovat: je to API do uživatelského prostoru. Jakmile bude LIRC začleněno, jeho API bude vytesáno do kamene, takže jakékoliv problémy s API je potřeba vyřešit předtím. LIRC, vyvíjený mimo hlavní řadu, se nedržel vývoje vstupního subsystému, takže se nechová jako ostatní vstupní ovladače - dokonce ani jako ovladače pro infračervené dálkové ovládače ve stromě. Použití jaderného parseru příkazové řádky v minimálně jednom ovladači jistě vyvolává vrásky; tento druh interakcí by měl skutečně být řešen pomocí ioctl() nebo sysfs. Všehovšudy je těžké si představit, že by byl tento kód začleněn, dokud nebudou vyřešeny všechny problémy jeho API.
Změna API LIRC samozřejmě povede k dalším problémům. Je zde kód v uživatelském prostoru, který na současném API závisí; jakékoliv změny tento kód znefunkční. Jaderná komunita tomuto problému určitě porozumí, ale pravděpodobně se jím nenechá odchýlit. S udržováním produkčního jaderného kódu mimo hlavní řadu je spojeno mnoho rizik; jedním z těchto rizik je, že vaše zavedené API nebude komunitou jaderných vývojářů akceptováno. Změna API tedy může jednoduše být cenou za takto pozdní zařazení LIRC do hlavní řady.
Měla by to být cena, kterou stojí za to zaplatit. Jakmile bude LIRC v hlavní řadě, zainteresovaní vývojáři budou pracovat na tom, aby kód splňoval standardy jádra. Komunita zajistí, aby se vyvíjely. Všichni uživatelé Linuxu dostanou LIRC ovladače v jádře bez potřeby řešit externí balíčky. Dostat se do tohoto stavu může být poněkud frustrující pro uživatele dálkových ovladačů a (obzvláště) pro vývojáře, kteří se ujali úkolu dostat tento kód do hlavní řady. Nicméně jakmile to bude hotové, dálkové ovladače budou obyčejný hardware podporovaný Linuxem tak, jako všechno ostatní.
Patch, který přidává několik bezpečnostních testů před spuštěním samotného systémového volání, by se zdál být rozumným přídavkem do jádra, ale protože je to přinejmenším polovičaté opatření, obdržel méně než nadšené přijetí. Zabránit rootkitům - malwaru, který mění jádro, aby skryl svou přítomnost a funkci - měnit tabulky systémových volání, bylo zdůvodněním tohoto patche, ale fungovalo by to pouze proti současným odrůdám rootkitů. Jakmile by na takovou změnu došlo, tvůrci rootkitů by prostě zareagovali změnou svého modu operandi.
Je mnoho možných způsobů, jakým může root - nebo malware běžící pod rootem - modifikovat linuxový systém, aby spouštěl kód rootkitu. Některé v současnosti "oblíbené" rootkity modifikují tabulku systémových volání, i když je zdánlivě neměnná. O některých vyhledávačích malwaru je známo, že tuto techniku používají také. V obou případech jsou některá systémová volání přesměrována ze standardního jaderného kódu na kód, který žije jinde. Tento kód běžící v jaderném módu potom může v systému udělat, cokoliv se mu zachce.
Arjan van de Ven navrhl patch, který se připojí do vstupního kódu systémového volání a zkontroluje adresu tohoto volání, aby se ujistil, že je mezi adresami obsazenými jaderným kódem. Změnu a její dopad popisuje takto:
Připojený patch sice zjevně neznamená dokonalou ochranu proti malwaru, ale přidává několik nenáročných testů do cesty syscallu, aby ověřil, že je systémové volání skutečně stále v oblasti jaderného kódu, a ne v nějaké jiné, jako třeba tam, kde je nahraný rootkit.
Režie je naprosto minimální; 2 cykly nebo méně. (To protože skoky se predikují správně a zbytek kódu je téměř perfektně paralelizovatelný... a nepřímé volání funkce stejně znamená skok.)
Různí jaderní hackeři upozornili na vady související s tímto schématem. Jak to stručně řekl Andi Kleen:
Tohle prostě znamená, že rootikity změní své chování tak, aby místo toho nahrazovaly první instrukci vstupních bodů. [...] Ochrana tedy bude mezi nulou a minimem, ale režie zde bude navždy.
Jedním z více zajímavých nápadů, které z diskuze vyplynuly, byla myšlenka Alana Coxe použít k vynucení ochrany hypervizor:
Jediné místo, kde zde lze zajistit nějaký rozdíl, je ve virtualizovaném prostředí tak, že se KVM naučí poskytovat hostovi stránky 'neodvolatelně pouze pro čtení', kde operačnímu systému hosta nebude dovoleno změnit práva zpět nebo tuto stránku virtuálně mapovat.
Ingo Molnár popsal poněkud komplikované schéma, které by mohlo zvýšit pravděpodobnost odhalení rootkitu, ale za poměrně vysokou cenu - jak v komplexitě překladu, tak v možnosti ladit výsledné jádro. Překladač by byl změněn tak, aby vkládal volání detekce rootkitů náhodně do jaderné binárky tak, aby bylo pro rootkit obtížné nebo nemožné je nalézt a vyhnout se jim. Rootkit by ale nakonec mohl jednoduše nainstalovat nové jádro, které by dělalo přesně to, co by chtěl, a pak vyvolat reboot nebo na něj počkat.
Bez nějakého druhu vynucení hardwarem (např. modulem důvěryhodné platformy [Trusted Platform Module]) nebo zamčené virtualizace je Linux proti útokům, které jsou vedeny pod rootem, bezbranný. Jádro lze změnit tak, aby vzdorovalo konkrétnímu typu útoku, jak to dělá Arjanův patch, ale jiné druhy útoku stále uspějí. Jde zde zjevně o situaci, kde jediným způsobem, jak vyhrát, je tuto hru nehrát, jak to - mezi jinými - poznamenal Pavel Machek v diskuzi.
Arjan nakonec tento patch odepsal jako cvičení v měření ceny tohoto druhu testování za běhu. Bylo to řešení za vcelku nízkou cenu, ale bez výrazného zisku. Skutečnou výhodou je, že jaderní vývojáři začali o tomto problému přemýšlet, což by mohlo vést k nějakému lepšímu výsledku.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Většinu naší snahy zaměřujeme na integraci. Naši konkurenti to vykládají jako "Canonical nepřispívá", ale mnohem přesnější je říci, že své přispívání měříme v efektivnosti toho, jak dostaneme nejnovější stabilní práci z upstreamu s bezpečnostními aktualizacemi co nejširšímu publiku, aby ji mohlo testovat a milovat. Podle mě je to velký příspěvek.Jinak řečeno: Ubuntu přispívá, jenom je potřeba trochu přiohnout běžné chápání toho slova v OSS.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz