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.
Jádro 2.6.26 je venku, Linus ho vydal 13. července. Pro ty, kteří si nás právě naladili: některé z větších změn v 2.6.26 zahrnují podporu PAT na architektuře x86, vázaná připojení pouze pro čtení, debugger KGDB, spoustu práce na virtualizaci a více. Mnoho detailů vizte na stránce o 2.6 na KernelNewbies.
Začleňovací okno 2.6.27 se otevřelo a v době psaní tohoto článku už bylo začleněno asi 3000 sad změn. Shrnutí toho, co bylo (zatím) do tohoto vývojového cyklu začleněno, najdete v článku níže.
Aktualizace stabilního jádra 2.6.25.11 byla vydána 13. července. Obsahuje jednu opravu pro lokálně zneužitelnou chybu (omezenou na systémy s x86_64).
Jinak řečeno, svůj patch jsem vlastně netestoval. Od toho jsou uživatelé!
6924d1ab8b7bbe5ab416713f5701b3316b2df85b je umělecké dílo. Je to tetris v ascii-art? Obrázek magického oka? Rozhodněte vy! V gitk vypadá dokonce ještě efektněji.
-- Dave Jones
![[Umění Inga Molnára]](/images/clanky/bourek/gitk-octopus.png)
-- Ingo Molnár
Ale také si dokážu představit, že druhé číslo bude "rok" a 2008 by dal 2.8, o rok později by první vydání v roce 2009 bylo 2.9.1 (a pravděpodobně bych se vyhnul ".0", protože to opět navozuje dojem, že to je "nové, neotestované vydání", což u číslování založeného na datu není pravda.) Pak v roce 2010 by bylo 3.0.1 atd...
Každopádně musím říct, že na číslování nemám nějak vyhraněný názor. Mám ale podezření, že ostatní ano, a jsem si téměř jistý, že to je absolutně perfektní téma typu "natírání kůlny", ve kterém budou tisíce lidí velmi vášnivě posílat svá mínění o tom, proč zrovna jejich barva je pro to natírání úplně nejlepší.
-- Linus Torvalds otevírá plechovku červů
Vskutku se omlouvám za to, že jsem revidoval kód na monitoru, který je větší než tvůj. Kdybychom jenom mohli zajistit, aby všichni vývojáři Linuxu používali menší monitory, kvalita kódu by se jistě zvýšila.
-- Herbert Xu
A zjevně bychom měli mít nějakou verzi firmwaru, která bude k dispozici v jádře, pokud to bude možné. Ale nelíbilo by se mi, kdyby byla 1:1 s konkrétní verzí ovladače - protože v takové chvíli už to vypadá jako jeden výrobek a pokud jde o více než o pouhé spojení, není to pro většinu našeho firmwaru použitelné. (Nemyslím si, že bychom měli zdrojové kódy ve více než jednom nebo dvou případech.)
Po vydání 2.6.26 Linus neztrácel čas; začleňovací okno 2.6.27 otevřel po méně než 24 hodinách. V době psaní tohoto článku proces sotva začal, začleněno bylo pouhých 3000 sad změn. Zatím tedy nemáme kompletní obraz toho, co bude v příštím vydání jádra. Můžeme se nicméně podívat na to, co bylo začleněno doteď.
Změny viditelné pro uživatele zahrnují:
Nové ovladače pro
Stará architektura "ppc" byla odstraněna; všechny platformy jsou nyní podporovány integrovaným kódem architektury "powerpc".
Filtr SCSI příkazů - který určuje, které SCSI příkazy mohou být poslány zařízení podle druhu uživatele - lze nyní nastavit pro každé zařízení zvlášť a změnit přes sysfs.
Blokový subsystém nyní podporuje hardware, který umožňuje kontrolovat integritu dat; to umožní zachytit některé druhy chyb předtím, než jsou dotyčná data navždy ztracena. Vizte níže, kde najdete více informací o vlastnosti integrity blokové vrstvy.
Linuxový bezpečnostní modul "dummy" byl odstraněn; výchozím modulem se stal modul capabilities.
Šifrovací kód získal podporu pro RIPEMD-128, RIPEMD-160, RIPEMD-256 a RIPEMD-320 hashovací algoritmy. Je podporováno asynchronní hashování, které je implementováno "cryptd" softwarovým crypto démonem.
Xen má nyní podporu pro ukládání a obnovování virtuálních strojů - s možností migrovat je mezitím na jiného hostitele.
Nový virtuální soubor /sys/firmware/memmap ukazuje mapu paměti, jak byla nakonfigurována BIOSem předtím, než nabootovalo jádro.
Byl začleněn lehký sledovací framework ftrace. Více informací o něm vizte v Documentation/ftrace.txt
Byl začleněn nástroj mmiotrace. MMiotrace zachytává a vypisuje přístupy do paměťově mapovaného I/O, díky čemuž je užitečný při reverzním inženýrství binárních ovladačů.
Architektury ARM a powerpc nyní podporují nástroj latencytop.
Kód RDMA získal podporu pro Infiniband operace "rozšíření pro základní správu paměti". Kód IP-přes-Infiniband nyní může provádět vykládání při rozsáhlém příjmu [large receive offload, LRO]
Do souborového systému ext4 byla přidána podpora pro zpožděné alokace. Ext4 se tak co se vlastností týče blíží ke svému cíli.
SATA vrstva má nyní podporu pro správu diskových šasi [enclosure management]; to systému umožňuje dělat věci, jako je blikání LED, která v rozsáhlém úložišti indikuje specifický disk.
Vrstva binární kompatibility SGI IRIX byla odstraněna.
Změny viditelné pro vývojáře jádra zahrnují:
Funkce register_security() byla odstraněna. Bezpečnostní moduly, které chtějí implementovat skládání [stacking], to musí udělat explicitně.
Typ request_queue_t je konečně pryč; blokové ovladače by místo něj měly použít struct request_queue
Byl začleněn docela velký kus práce na odstranění velkého jaderného zámku. Pro znaková zařízení již metoda open() ze struct file_operations není chráněna BKL. Volání fasync() také ztratila ochranu BKL.
Bylo konvertováno mnoho ovladačů, aby používaly zavaděč firmwaru, což těm, kteří jsou tomu nakloněni, umožňuje vyhodit firmware z jádra. Více informací o práci na firmwarech najdete v článku Odstraňování firmwaru.
Práce na API ve vrstvě i2c pokračuje; nyní je tam schopnost autodetekce, která umožňuje ovladačům nového stylu automaticky detekovat zařízení na sběrnicích.
SCSI vrstva získala novou podporu pro "manipulátory zařízení", která se nejvíce zabývá správou více cest [multipath]. Část tohoto kódu byla přesunuta z device mapperu.
Později se vraťte a přečtěte si další epizodu seriálu Co přichází v 2.6.27.
Člověk si rád myslí, že disky jsou spolehlivá úložiště dat. Dokud se nic nepokazí tak, že se ze zařízení zakouří, bloky zapsané na disk by se skutečně měly vrátit se stejnými bity na stejných místech. Skutečná situace ale není tak povzbudivá, obzvláště když se jedná o hardware z místního obchodu s hardwarem. Příběhy o blocích, které byly poškozeny nebo zapsány na jiné místo, než bylo zamýšleno, jsou běžné.
Z tohoto důvodu trvá zájem o souborové systémy, které pro data uložená na blokových zařízeních používají kontrolní součty. Místo toho, aby věřil zařízení, že úspěšně uložilo a načetlo blok, může souborový systém porovnat kontrolní součty a být si jistý. Nějaké počítání kontrolních součtů provádějí také paranoidní aplikace v uživatelském prostoru. Říká se, že kontrolní součty v BitKeeperu zachytily mnoho problémů s poškozením; následnické nástroje, jako je git, mají kontrolní součty ve svých datových strukturách hluboko zadrátované. Jestliže disková jednotka poškodí gitový repozitář, uživatel se o tom dozví spíš dříve než později.
Kontrolní součty jsou užitečný nástroj, ale mají jeden malý problém: nesouhlas kontrolního součtu má tendence přijít až ve chvíli, kdy už je příliš pozdě na to, aby se dal nějak využít. V době, kdy si souborový systém nebo program všimnou, že blok na disku není takový, jaký původně byl, původní data mohou být dávno pryč a neobnovitelná. Poškození bloku na disku se ale často stane během procesu přenášení dat k disku; bylo by určitě hezké, kdyby disk sám mohl použít kontrolní součet, aby se ujistil, že (1) data se k němu dostala neporušená a (2) disk sám je nepoškodil.
Za tímto účelem sestavilo několik skupin zabývajících se standardizací schémata pro začlenění kontroly integrity dat přímo do hardwaru samotného. Tyto mechanismy mají obvykle formu přidaných osmi bytů ke každému bloku 512 bytů. Hostitelský systém generuje kontrolní součet, když připravuje blok k zápisu na disk; tento kontrolní součet potom následuje data skrz sérii hostitelských řadičů, RAID řadičů, síť atd., kde hardware při každém kroku kontrolní součet testuje. Kontrolní součet je uložen v datech a když jsou data v budoucnosti čtena, kontrolní součet jde s nimi, opět testován při každém kroku. Výsledkem by mělo být, že problémy s poškozením dat jsou zachyceny okamžitě a způsobem, který umožňuje identifikovat, která komponenta v systému je na vině.
Není potřeba říkat, že tento mechanismus kontroly integrity vyžaduje podporu operačního systému. Od jádra 2.6.27 bude Linux díky Martinu Petersenovi tuto podporu mít, alespoň pro SCSI a SATA disky. Dobře napsaný soubor s dokumentací zahrnutý v patchích integrity dat si představuje tři místa, ve kterých může být prováděno generování a testování: v blokové vrstvě, v souborovém systému a v uživatelskému prostoru. Zdá se, že skutečná ochrana "od začátku do konce" potřebuje ověření v uživatelském prostoru, ale pro teď je důraz na provedení této práce v blokové vrstvě nebo souborovém systému - i když v době psaní tohoto článku neexistují v hlavní řadě žádné souborové systémy, které by měly povědomí o testování integrity.
Ovladače blokových zařízení, která mohou zvládnout data integrity, potřebují registrovat v blokové vrstvě nějaké informace. To se provede naplněním struktury blk_integrity a předáním blk_integrity_register(). Kompletní detaily najdete v dokumentu; ve zkratce struktura obsahuje dva ukazatele na funkce. generate_fn() generuje kontrolní součet pro blok dat a verify_fn() tento kontrolní součet ověří. Také jsou zde funkce, které k bloku připojí značku - vlastnost, kterou podporují některé disky. Data uložená v značce mohou být využita kódem na úrovni souborového systému například k tomu, aby se zajistilo, že blok bude skutečně částí souboru, ke kterému patří.
Bloková vrstva bude v nepřítomnosti souborového systému, který ověřuje integritu, připravovat a testovat data s kontrolním součtem sama o sobě. Za tímto účelem byla rozšířena struktura bio o nové pole bi_integrity, které ukazuje na strukturu bio_vec, která popisuje informaci o kontrolním součtu a dalším úklidu. Standardy o integritě byly naštěstí napsány tak, že umožňují ukládat informace o kontrolních součtech odděleně od dat; alternativou by jinak bylo modifikovat celý linuxový systém správy paměti, aby tuto informaci udržoval. Informace tak jde do oblasti bi_integrity; pro přenos dat na a z disku naráz se používají rozsyp/sesbírej [scatter/gather] DMA operace.
Souborové systémy se schopností řešit integritu, až se objeví, budou moci od blokové vrstvy převzít generování a ověřování kontrolních součtů. Volání bio_integrity_prep() připraví danou strukturu bio pro ověřování integrity; pak bude na souborovém systému, aby generoval kontrolní součet (pro zápisy) a ověřoval ho (při čtení). Také je k dispozici sada funkcí pro správu dat značek; detaily opět vizte v dokumentu.
Jednou z více obtěžujících a dlouho existujících nepříjemností v linuxové blokové vrstvě je limit počtu oddílů, které lze vytvořit na jednom zařízení. IDE zařízení jsou schopna zvládnout 64 oddílů, což je obvykle dost, ale SCSI zařízení jich může zvládnout pouze 16, a to je jeden rezervován pro celé zařízení. S tím, jak se tato zařízení zvětšují a aplikace, které mohou těžit z oddělení souborových systémů (například virtualizace), jsou stále populárnější, je tento limit čím dál tím protivnější.
Zajímavé je, že práce potřebná k překonání tohoto problému byla již udělána před několika lety, když byla čísla zařízení rozšířena na 32 bitů. V roce 2004 byla navržena komplikovaná schémata, která rozšiřovala počet oddílů beze změny existujících čísel zařízení, ale tento přístup nebyl nikdy přijat. Mezitím rozšiřující se používání nástrojů jako udev víceméně eliminovalo potřebu kompatibility čísel zařízení; ve většině distribucí již nejsou přetrvávající soubory zařízení.
Když tedy Tejun Heo znovu řešil problém limitu oddílů, neobtěžoval se s žádnými schématy velkého přesouvání. Místo toho se s jeho sadou patchů bloková zařízení prostě přesouvají na nové hlavní číslo zařízení [major device number] a všechna vedlejší [minor] čísla jsou přiřazována dynamicky. To znamená, že žádné blokové zařízení nemá stabilní (mezi booty) číslo; také to znamená, že vedlejší čísla pro oddíly na stejném zařízení nemusí být nutně seskupena. Vzhledem k tomu, že nikdo ve skutečnosti na čísla zařízení v současných distribucích nekouká, nic z toho by nemělo vadit.
Tejunův patch je zajímavé cvičení v postupné evoluci rozhraní směrem ke konečnému cíli s mnoha mezikroky. API, které vidí blokové ovladače, se nakonec mění jen velmi málo. Přibyl nový příznak (GENHD_FL_EXT_DEVT), který disku umožňuje použít rozšířená čísla oddílů; jakmile jsou vyčerpána vedlejší [minor] čísla, která má k dispozici alloc_disk(), čísluje se každý další oddíl v rozšířeném prostoru. Nicméně se zdá, že zamýšleným použitím je nealokovat tradiční vedlejší čísla vůbec - alokování disků voláním alloc_disk(0) a vytvořením všech oddílů v rozšířeném prostoru. Tejunův patch způsobuje, že IDE i sd ovladače alokují struktury gendisk tímto způsobem, takže přesouvají všechny disky na většině systémů do (sdíleného) prostoru rozšířených čísel.
I když moderní distribuce nemají potíže s dynamickými čísly zařízení (a jmény, když jsme u toho), těžko si lze představit, že by taková změna byla v celé uživatelské základně Linuxu zcela bez problémů se správou systému. Distributoři mohou být stále ještě nervózní z trápení se po změně v PATA ovladačích, která změnila jména disků na instalovaných systémech. Proto není zcela jasné, kdy se Tejunovy patche mohou dostat do hlavní řady nebo kdy distributoři začnou jejich funkce využívat. Tlak na možnost mít více oddílů ale pravděpodobně nezmizí, takže tyto patche si svou cestu do jádra mohou najít zanedlouho.
I ten nejběžnější pozorovatel mailové konference linux-kernel si musel všimnout, že ve stínu flamewaru o firmwarech se také krčí rozvášněná diskuze o řešení bezpečnostních záležitostí. Objevily se také pokusy změnit tuto místní bitvu na mnohakonferenční regionální konflikt. Nalezení správné cesty, jak se potýkat s bezpečnostními problémy, je obtížné pro jakýkoliv projekt a jádro není výjimka. Jestli tato diskuze povede k nějakým změnám, se ještě uvidí, ale přinejmenším nám poskytuje jasný pohled na to, kde jsou neshody.
Tentokrát se diskuze rozhořela v reakci na stabilní aktualizace jádra 2.6.25.10. Oznámení říkalo, že Všem uživatelům jádra 2.6.25 se SILNĚ doporučuje aktualizovat na toto vydání, ale neříkalo proč; žádný z patchů v tomto vydání nebyl označen jako bezpečnostní problém. Jak se tak stává, v této aktualizaci byly opravy spojené s bezpečností; někteří uživatelé jsou rozčílení, že tak nebyly explicitně nazvány. Došli až do bodu, kde obvinili vývojáře jádra z toho, že skrývají bezpečnostní problémy.
Tyto problémy jsou opraveny patchi s relativně neškodně znějící zprávou v popisem commitu (například "x86_64 ptrace: oprava úniku sys32_ptrace task_struct") a uživatelům není sděleno, že to byla bezpečnostní oprava. To je obratem považováno za uvádení uživatelů do nebezpečí, protože (1) neví, že mají aktualizaci aplikovat a (2) nemají jasný obraz o tom, kolik bezpečnostních problémů se v jaderném kódu vynořuje. Takže, jak to řekl "pageexec" (či "PaX Team"):
Problém, o kterém jsem začal mluvit, je, že v Documentation/SecurityBugs je jenom jedna politika (plné odkrytí [full disclosure]), ale ve skutečnosti se jedná úplně jinak a Linus to nyní dokonce přiznal. Problém vyrůstající z této inkonzistence je, že lidé spoléhající na politiku odkrývání budou dělat špatná rozhodnutí a potenciálně ohrožovat své uživatele. Z této situace vedou dvě cesty: buď se drž plného odkrývání i ve skutečnosti, nebo dej světu vědět, že nechceš. V obou případech lidé přizpůsobí své procesy řešení bezpečnostních chyb a všem bude lépe.
Obvinění, že jádro se nedrží politiky plného odhalení, má dva aspekty: jaderná vydání nezdůrazňují fakt, že byly opraveny bezpečnostní problémy, a tvrdí se, že zprávy ke commitům zamlžují bezpečnostní opravy. Co se druhého obvinění týče, v určitém ohledu je to pravda, protože Linus připouští, že mění logy commitů, které diskutují bezpečnostní problémy příliš explicitně.
Doslova kreslím čáru u všeho, co je jednoduše grepovatelné. Jestliže ještě nejde o hodně publikovanou bezpečnostní záležitost, nechci, aby ji pomohlo najít jednoduché "git log + grep".
Jinak řečeno, neplánuji zprávy ani je nezatemňuji, takže "přetečení" klidně může být součástí zprávy, protože jednoduše popisuje opravu. Takže netvrdím, že zprávy nikdy nemohou nikomu vytipovat zajímavé commity, na které se podívat, navíc nemám ani zájem dělat to nějak spolehlivě.
Jeho cíl je jasný: aspoň trochu ztížit život lidem, kteří prohledávají logy commitů ve snaze najít slabiny, které lze zneužít. Lze se dohadovat o tom, jestli tato politika znamená skrývání bezpečnostních problémů, nebo jestli je efektivní v redukci zneužití (a mnoho lidí dalo najevo vůli se dohadovat), ale faktem je, že to je politika, kterou se Linus momentálně řídí. Z jeho pohledu je začlenění opravy zároveň odhalením problémů a není nutné být více explicitní.
Tento pohled se dotýká celého procesu bezpečnostních aktualizací, který je společný pro většinu komunity. Linus nerespektuje žádné politiky embarga nebo zpožděného odhalení a kritizuje "celý bezpečnostní cirkus", který podle jeho mínění dává důraz na špatnou věc:
Z lidí, co se zabývají bezpečností, to dělá 'hrdiny', jako kdyby lidé, kteří opravují normální chyby nebyli až tak důležití. Ve skutečnosti všechny ty nudné normální chyby jsou mnohem důležitější, už protože jich je mnohem víc. Nemyslím si, že by nějaká velkolepá bezpečnostní díra měla být oslavována nebo ošetřována jako něco "zvláštního" víc než náhodný velkolepý pád kvůli špatnému zamykání.
Kromě toho je často těžké říci, které patche jsou opravdu bezpečnostní opravy. Občas se objevuje tvrzení, že všechny chyby mají vliv na bezpečnost; že se většinou jedná jenom o záležitost nalezení způsobu, jak je zneužít. Takže explicitní označení bezpečnostních oprav přináší riziko, že se odvede pozornost od všech ostatních oprav, z nichž mnohé mohou ve skutečnosti být také bezpečnostní. Proto Linus říká:
Jestliže si někdo myslí, že je bezpečnější aplikovat (nebo aktualizovat) jenom určité patche, které jsou označeny jako bezpečnostní, pak vynechává všechny ty, které tak označeny nejsou.
Takže proč bych měl přidávat nějakou značku, ve kterou sám nevěřím a o které si myslím, že je to z větší části jenom bezpečnostní divadlo.
Jinak řečeno, aktualizace stabilního jádra vycházejí s patchi, o kterých se ví, že jsou to bezpečnostní opravy. Někteří lidé zjevně věří, že SILNÉ doporučení aktualizace není dostatečné upozornění na tento fakt. Zdá se, že se objevil trend znemožnit explicitní rozeznání bezpečnostních záležitostí ve stabilních vydáních. Přidávání CVE čísel bylo kdysi obvyklé; v sérii 2.6.25 mají tato čísla v changelozích jenom 2.6.25.1, 2.6.25.2 a 2.6.25.5. Vskutku je pravda, že prosté čtení changelogu stabilního vydání neřekne uživatelům, jestli tato vydání opravují relevantní bezpečnostní záležitosti.
Na tuto stížnost je samozřejmě také mnoho odpovědí. Skutečné informace jsou ve zdrojovém kódu a ten je vždycky veřejný. Navíc není pravděpodobné, že by pro většinu uživatelů byly opravy ve stabilních sériích tak relevantní; používají jádra od distributorů, která jsou mnoho měsíců za -stable sérií a která mohou (nebo nemusí) být specifickým problémem postižena. Uživatelé, kteří jsou znepokojeni bezpečnostními otázkami ve svém jádře, mají někoho, na koho se mohou obrátit: na své distributory. Distributoři Linuxu dodržují pravidla odhalování, mají tendence velmi důkladně opravovat známé bezpečnostní problémy a tyto opravy šířit k uživatelům. Co se uživatelů, kteří potřebují dlouhodobou podporu na vysoké úrovni, týče, jsou distributoři, kteří více než ochotně za poplatek takovou službu poskytnou.
Jak je obvyklé, opět se jedná o zdroje. Bylo by hezké, kdyby někdo sledoval proud patchů (dobře přes 100 patchů za den v hlavní řadě) a identifikoval každý, který má bezpečnostní dopady. Tato osoba by pro každý patch mohla zjistit, která verze jádra byla poprvé zranitelností postižena, zajistila CVE číslo a vydala hezky formátovanou zprávu. To je ale obrovská práce a je nepravděpodobné, že by ji někdo dělal bez kompenzace po jakoukoliv dobu. Takže by za to někdo musel platit. A to je ve velkém rozsahu to, co dělají distributoři teď - s hezkým přídavkem, že backportují opravy do jader, která podporují.
Stojí za to poznamenat, že tito distributoři si příliš nestěžovali na to, jak jsou teď řešeny bezpečnostní opravy. Místo toho stížnosti přišly hlavně od správců projektu mimo strom grsecurity, který by z cynického úhlu pohledu mohl těžit ze zviditelnění bezpečnostních problémů linuxového jádra.
Bez ohledu na platnost takového obvinění může být určitá hodnota v tom, že se ptají. Je dobré mít jasný náhled na to, jaké jsou v kusu kódu bezpečnostní problémy. I kdyby nic jiného, pomáhá to projektu porozumět, kde se nachází s ohledem na bezpečnost a jestli se věci zlepšují nebo zhoršují. Bylo by tedy hezké, kdyby byli jaderní vývojáři o něco pečlivější a organizovanější v tom, jak sledují bezpečnostní záležitosti, stejně jako se během několika posledních let zlepšilo sledování regresí. Takové vylepšení se ale neobjeví, dokud se někdo nerozhodne dát si tu práci. Skutečné věnování času dokumentování jaderných bezpečnostních záležitostí by bylo mnohem užitečnější než stěžování si v mailových konferencích.
Tímto článkem přispěl Greg Kroah-Hartman
Rád bych se pokusil objasnit některé body ve článku "Řešení bezpečnostních problémů v jádře" od Jonathana Corbeta.
Především musím říci, že mluvím pouze za sebe, ne za druhou polovinu Linux -stable týmu Chrise Wrighta, který se mnou může naprosto nesouhlasit, ne za další jaderné vývojáře, kteří pomáhají s aliasem security@kernel.org, ne za svého současného zaměstnavatele Novell. Také prosím vezměte na vědomí, že veškerý vývoj ve -stable dělám ve svém volném čase a není to žádnou součástí mé stávající práce.
To by bylo. A teď: Mám námitky k několika věcem uvedeným v původním článku:
Zdá se, že se objevil trend znemožnit explicitní rozeznání bezpečnostních záležitostí ve stabilních vydáních. Přidávání CVE čísel bylo kdysi obvyklé; v sérii 2.6.25 mají tato čísla v changelozích jenom 2.6.25.1, 2.6.25.2 a 2.6.25.5. Vskutku je pravda, že prosté čtení changelogu stabilního vydání neřekne uživatelům, jestli tato vydání opravují relevantní bezpečnostní záležitosti.
V mnoha případech, kdy děláme vydání -stable, nejsou pro některé s "bezpečností" spojené problémy, které opravujeme, CVE čísla vydána. To se stává, když se oprava objeví nejprve v Linusově stromě a pak je forwardována na alias stable@kernel.org s "tohle je potřeba hned vydat" nebo prostě tím, že si lidé uvědomí, že by mělo být alokováno CVE číslo, až později.
A ano, trend je omezit explicitní rozpoznání bezpečnostních záležitostí přesně podle Linusova výroku, ze kterého cituješ.
Tohle se týká toho, kdo jsou uživatelé -stable sérií jádra. Osobně to vidím tak, že tato jádra jsou pro dvě různé skupiny lidí:
První skupina by měla vždy aktualizovat na nejnovější verzi -stable, protože spoléhají na to, že -stable tým jim vždy poskytne nejnovější opravy, o kterých ví, že jsou potřeba. Jednoduché označování věcí značkou "spojené s bezpečností" může být, jak Linus zdůraznil, zavádějící. Záznamy v changelogu by měly všem uživatelům ukázat, co bylo opraveno, a pokud provozují stroj, který ten kód používá, měli by aktualizovat. Je to takhle jednoduché.
Ve skutečnosti jsem se ve vydání 2.6.25.11 snažil přesně toto říci:
Obsahuje jednu opravu chyby, každému uživateli jádra 2.6.25 na x86_64 s nedůvěryhodnými lokálními uživateli se velmi SILNĚ doporučuje aktualizovat.
Jde to vůbec říct jasněji? Potřebuje uživatel -stable stromu, který musí být technicky kompetentní, aby byl vůbec schopen takovou věc udělat, vědět ještě víc, má-li se rozhodnout, jestli na svém stroji aktualizovat? Zdá se, že lidé jsou rozčileni z toho, že již nepoužívám kouzelná slůvka "bezpečnostní oprava", což je pravda, to už neříkám. Jak poznamenal Linus a další, označování chyb jako "spojených s bezpečností" nepomáhá, obzvlášť když se ne všichni shodnou - nebo dokonce v době vydání ani neví - jestli chyba má dopad na bezpečnost, nebo ne.
Také si všimněte, že toto vydání neodkazuje CVE číslo. To je proto, že v této chvíli ještě není žádné přiřazeno, přestože jsme relevantní skupiny o přiřazení požádali. Nikdy nechci zdržovat vydání čekáním na takové číslo, takže je v budoucnu nebudu v -stable vydáních používat, pokud nebudou obsaženy v původním záznamu v changelogu v Linusově stromě.
Druhá skupina, distributoři, se zdá být spokojena s tím, jak jsou v současnosti vedena -stable vydání. Mají možnost vybrat si z oprav, aplikovat je na své starší verze jádra a dodávat je zákazníkům podle toho, jak se jim to zdá vhodné. Všechna distra ví, které věci mají souvislost s bezpečností tím, že znají a rozumí kódu a modelu ohrožení, protože mají vývojáře, kteří řeší takové bezpečnostní záležitosti a dělají to léta.
Ve svém shrnutí tvrdíš:
Je dobré mít jasný náhled na to, jaké jsou v kusu kódu bezpečnostní problémy. I kdyby nic jiného, pomáhá to projektu porozumět, kde se nachází s ohledem na bezpečnost a jestli se věci zlepšují nebo zhoršují. Bylo by tedy hezké, kdyby byli jaderní vývojáři o něco pečlivější a organizovanější v tom, jak sledují bezpečnostní záležitosti, stejně jako se během několika posledních let zlepšilo sledování regresí.
Myslím si, že jednotliví vývojáři jádra všichni docela dobře ví, kde jsou bezpečnostní problémy s jejich kódem. Toto tvrzení podporuje fakt, že tito vývojáři jsou obvykle ti, kteří dělají opravy a říkají -stable týmu, že specifický patch je potřeba vydat.
Zdá se, že to, co požaduješ, je způsob, jak klasifikovat chyby a opravy v jaderném stromě jako "spojené s bezpečností", nebo ne. A tím se vracíme k původnímu Linusovu tvrzení. Zkusit tohle dělat znamená opomíjet chyby, které takto označené nejsou, s tím, že to nemá cenu. Nicméně, jestli se najde někdo, kdo by pro jadernou komunitu chtěl tu práci dělat a časem se to ukáže jako přínosné, budu první ve frontě těch, kteří řeknou, že se spletli.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Někdo z adminů to změnil na "krabici"Vůbec na ten překlad nejsem pyšný, ale změnil jsem to jen proto, aby to dávalo smysl (při čtení před vydáním jsem to pochopil tak, že jde o nějaké rámy, do který se to zavírá, takže mi ohrazování nepřišlo tak špatné). Rád si nechám poradit vhodnější výraz.
2.9.2008 14:33
Pavel Stárek | skóre: 44
| blog: Tady bloguju já :-)
| Kolín
Tak to místo krabice bych tam dal radši box.Pokud se mluví o něčem, jako je tohle, tak na alze používají termín "diskový box". Nicméně "diskové šasi" taky ujde (a je to česky)
Jinak z toho stejne vznikne neco, co je v principu spatne (offloading), nebo v lepsim pripade to sice vyznam bude mit spravny, ale stejne tomu nikdo bez hranatych zavorek nebo prekladu zpet do anglictiny rozumet nebude...Proto tam ty hranaté závorky jsou. Tenhle spor překládat do češtiny vs. nechávat v angličtině se táhne už léta. (Argument pro překlad - čtou nás i lidi, kteří neumí moc anglicky - argument proti - překlad nemusí být správný a někdo by ho nemusel pochopit.) Výsledek - přeložit a zároveň ponechat původní anglický termín v hranatých závorkách - vznikl jako kompromis ještě dřív, než jsem začal překládat. Proto se ho hodlám držet, dokud mi Robert neřekne jinak. Ano, někdy vím, že přeložený termín není správně a pravděpodobně existuje i lepší varianta. Jenže ji neznám, takže uvádím překlad i původní termín proto, aby poučený čtenář, který zná lepší překlad, ho mohl v diskuzi navrhnout. Bohužel zatímco kritiky se tady objevuje hodně, lepších návrhů jsem zatím moc neviděl.
Ano, někdy vím, že přeložený termín není správně a pravděpodobně existuje i lepší varianta. Jenže ji neznám, takže uvádím překlad i původní termín proto, aby poučený čtenář, který zná lepší překlad, ho mohl v diskuzi navrhnout. Bohužel zatímco kritiky se tady objevuje hodně, lepších návrhů jsem zatím moc neviděl.Problem je v tom, ze nektere terminy proste v cestine ekvivalent nemaji a proto se tezko nejakeho doporuceni dockate. Jediny spravny preklad slova offloading je slovo offloading. Kdo dany termin nezna, tomu ani Vami vymyslena ceska varianta nerekne, co se tam doopravdy deje, kdo termin zna je akorat zdrzen hledanim nejblizsich hranatych zavorek => IMHO zavadeni novotvaru ktere se v praxi nepouzivaji nicemu/nikomu neprospeje.
4.9.2008 13:04
multi | skóre: 38
| blog: JaNejsemOdsut
Slovo offloading je odvozeno od zatezeAno, to je pravda, ale když se podíváš, co LRO dělá, tak ten překlad začne dávat smysl. LRO odlehčuje systému tím, že přebírá větší dávky paketů najednou, takže překlad "vykládání" vůbec není nesmyslný.
nebylo by jednodussi se proste na preklad slov, u kterych neznate vyznam nebo u kterych cesky ekvivalent vubec neexistuje, vykaslat a nechat je v originale?Bylo, ale pak by vůbec nemusely vycházet překlady. Když už je to překlad, tak by měl být srozumitelný i pro ty, kdo anglicky neumějí, nebo se nevyznají v konkrétní problematice/originální terminologii. Tohle už se tu řešilo hodněkrát. Proto jsou u spousty výrazů v hranatých závorkách originály.
Ja si myslim, ze mirne nesmyslny je. Offloading neni vykladani, ale presouvani zateze (alespon v teto souvislosti). Existuji tzv. offload engines, ktere za procesor pocitaji nektere veci samy, napr. sitova karta, ktera si sama pocita checksum-y nebo iSCSI offload engines, ktere dokazou pracovat primo s iSCSI protokolem a procesor se s prenosem dat nemusi starat jeste o jejich zabaleni do TCP streamu, spocitani checksum-u apod. Preklad slova enclosure se mi taky moc nelibi, ale popravde receno ted nevim, jak bych to prelozil jinak. Snad jako drzak disku? Ramecek na disk? No, nevim. Ale krabice mi taky uplne vhodna neprijde... Zdravi HonzaSlovo offloading je odvozeno od zatezeAno, to je pravda, ale když se podíváš, co LRO dělá, tak ten překlad začne dávat smysl. LRO odlehčuje systému tím, že přebírá větší dávky paketů najednou, takže překlad "vykládání" vůbec není nesmyslný.
Offloading neni vykladani, ale presouvani zateze (alespon v teto souvislosti). Existuji tzv. offload engines, ktere za procesor pocitaji nektere veci samy, napr. sitova karta, ktera si sama pocita checksum-y nebo iSCSI offload engines...Snižování zátěže při rozsáhlém příjmu?
Když už je to překlad, tak by měl být srozumitelný i pro ty, kdo anglicky neumějí, nebo se nevyznají v konkrétní problematice/originální terminologii.Tento 'inovativni' preklad anglickych terminu vychazi z predpokladu, ze prelozeny termin nejak pomuze k pochopeni textu. Myslim, ze tento predpoklad je zcela mylny - to plati pro bezna slova, ne pro odborne terminy - smysl odborneho terminu nelze urcit ze zneni slova (ci jazykovych asociaci daneho slova), ale pouze z toho, jak je dany termin pouzivan v odbornych textech. Zavadet novy cesky termin k nejakemu jevu si muze dovolit leda tak nekdo, kdo pise clanek specificky o tom jevu, takze z clanku je ten jev dostatecne specifikovan a tim termin zaveden. Ale vymyslet 'nove terminy' jen pri letmem zminovani o danem jevu je silne kontraproduktivni.
Tento 'inovativni' preklad anglickych terminu vychazi z predpokladu, ze prelozeny termin nejak pomuze k pochopeni textu.Rozhodně pomůže víc, než když se nepřeloží nic.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz