Gemini CLI umožňuje používání AI Gemini přímo v terminálu. Vydána byla verze 0.10.0.
Konference OpenAlt 2025 proběhne již příští víkend 1. a 2. listopadu v Brně. Nabídne přibližně 80 přednášek a workshopů rozdělených do 7 tematických tracků. Program se může ještě mírně měnit až do samotné konference, a to s ohledem na opožděné úpravy abstraktů i případné podzimní virózy. Díky partnerům je vstup na konferenci zdarma. Registrace není nutná. Vyplnění formuláře však pomůže s lepším plánováním dalších ročníků konference.
Samsung představil headset Galaxy XR se 4K Micro-OLED displeji, procesorem Snapdragon XR2+ Gen 2, 16 GB RAM, 256 GB úložištěm, operačním systémem Android XR a Gemini AI.
Před konferencí Next.js Conf 2025 bylo oznámeno vydání nové verze 16 open source frameworku Next.js (Wikipedie) pro psaní webových aplikací v Reactu. Přehled novinek v příspěvku na blogu.
Sovereign Tech Fund oznámil finanční podporu následujících open source projektů: Scala, SDCC, Let's Encrypt, Servo, chatmail, Drupal, Fedify, openprinting, PHP, Apache Arrow, OpenSSL, R Project, Open Web Docs, conda, systemd a phpseclib.
Bylo vydáno OpenBSD 7.8. S předběžnou podporou Raspberry Pi 5. Opět bez písničky.
Valkey (Wikipedie) byl vydán v nové major verzi 9.0. Valkey je fork Redisu.
Byly publikovány informace o kritické zranitelnosti v knihovně pro Rust async-tar a jejích forcích tokio-tar, krata-tokio-tar a astral-tokio-tar. Jedná se o zranitelnost CVE-2025-62518 s CVSS 8.1. Nálezci je pojmenovali TARmageddon.
AlmaLinux přinese s verzí 10.1 podporu btrfs. XFS bude stále jako výchozí filesystém, ale instalátor nabídne i btrfs. Více informací naleznete v oficiálním oznámení.
Společnost OpenAI představila svůj vlastní webový prohlížeč ChatGPT Atlas. Zatím je k dispozici pouze na macOS.
Současné vývojové jádro je 4.1-rc5, vydné 24. května. "Vydání 4.1 jde podle plánu, až na to, že podle načasování to vypadá, že se další začleňovací okno bude krýt s naší letošní rodinnou dovolenou. Uvidíme, jak to dopadne. Možná posunu vydání, abych se tomu vyhnul (nebo posunu otevření začleňovacího okna)."
Stabilní aktualizace: Žádné nebyly minulý týden vydané.
Myslím, že jako odborníci bychom měli často dělat chyby - viditelné chyby. Aspoň lidi nenapadne si myslet, že nemůžeme. Linus to takhle dělá už léta a očividně to funguje.
Kernel má schopnost vynutit si požadavek podpisu načítaných modulů již několik let. Do jádra se přitom nahrává ještě další kód, který podobnou kontrolou zatím neprochází. Jedním z příkladů je firmware, který se skrze jádro dostává do řadičů. V současné době se pracuje na přidání schopnosti kontrolovat firmware bloby (velké binární soubory), ale má to háček. Ne všichni si myslí, že je taková funkce zapotřebí.
Luis Rodriguez popsal svůj nápad na několika jaderných mailing listech. Na přepracování modul loaderu jádra momentálně pracuje David Howells a snaží se nahradit svůj, podomácku vyrobený mechanismus podepisování modulů, standardem PKCS#7. Podle Linuse přišel čas přijmout stejný standard pro podepisování různých souborů, které se nahrávají do jádra, firmwaru obzvláště.
V návrhu se počítá s tím, že by podpisy firmware (stejně jako vynucení podpisů modulů) bylo volitelné, bylo by možné postavit jádro bez této schopnosti. Většina firmwaru, nahrávaného linuxovými ovladači, se ukládá do firmwarového linuxového repozitáře. Tyto bloby by podepsal firmware maintainer, takže by byly zaveditelné ve výchozím nastavení. Luis navrhl, aby Linux Foundation vytvořila klíč X.509, který by se stal součástí zdrojového kódu jádra, a který by na oplátku našel využití při podepisování klíče maintainera firmwaru. Téma firmwaru mimo hlavní strom nikdo nenačal. Vždycky by ale mělo být možné přidat další klíč na jadernou klíčenku a povolit nahrání nového firmwaru.
Andy Lutomirsky se trochu bojí toho, jak by se s těmito klíči mělo nakládat. Obzvláště by byl rád, kdyby byla využitelnost každého klíče co možná nejvíce omezena. Klíče pro podepisování modulů by podle něj něměly fungovat pro firmware. Podpisy by také měly upřesnit, kde je třeba použít blob, aby se dalo předejít útokům v případě, že dojde k odeslání firmware ke špatnému zařízení.
Základní otázku však položili Alan Cox a Greg Kroah-Hartman: Proč se vůbec zabývat podepisováním firmware? Greg k tomu řekl:
Moc nechápu potřebu podepisovat něco, co nevím odkud a od jaké společnosti je, jen abych to poslal k samostatnému zařízení, které si s tím udělá co bude chtít, ať už je to podepsané nebo ne.
Oba si myslí, že mají-li být firmware podpisy kontrolovány, měla by to dělat zařízení, která tento firmware přijímají. Jinak bude jádro kontrolovat platnost obrazu firmware, o kterém stejně nemůže nic moc vědět.
Jak správně podotkl David Woodhouse, spočívá problém kontroly podpisu v zařízení v tom, že se nahrávaný firmware používá jako metoda snížení spotřeby hardwaru. Zavedením této šifrovací funkce přímo do zařízení (navíc takového, které ještě nemá nahraný operační software), by naopak zvýšilo jeho spotřebu a tím zmařilo původní záměr. Greg sice s tímto názorem nesouhlasil, ale zdá se, že hardware postrádající kontrolu podpisu firmware stejně jen tak nezmizí.
David ještě dodal, že bez IOMMU (I/O memory management unit) mohou škodlivá zařízení běžícímu systému uškodit. Ohrožený firmware může představovat atraktivní způsob, jak zaútočit na systém. Podle něj není podepisování firmware pouze způsob, jak ochránit operační systém, ale také služba prodejcům hardwaru.
Dalším důvodem proč chtít tuto funkci je fakt, že může sloužit pro ověření původu jiných souborů nahrávaných do jádra. Luis si dělá starosti hlavně o CRDA subsystém (central regulatory domain agent). CRDA se stará o právní stránku bezdrátových sítí v různých právních řádech po světě. Různé země mají různá pravidla. Týkají se frekvencí, výkonu a podobně. CRDA subsystém dohlíží na to, aby Linux fungoval podle pravidel daného místa.
Luis vyjádřil CRDA uznání za to, že nás dostalo ze situace, kdy výrobci bezdrátových adaptérů mohli odmítnout poskytnout free ovladače ke svým zařízením. Díky CRDA si výrobci mohou být jisti, že se jejich hardware používá vyhovujícím způsobem. Ovšem tato důvěra obstojí pouze v případě, kdy uživatelé nebudou moci samovolně modifikovat CRDA databázi. Za tímto účelem je databáze v současné době podepsaná. Na některých distribucích dojde před jejím načtením do jádra k ověření v uživatelském prostoru.
Problémem do budoucna může být použití specifického šifrovacího kódu subsystému. Napsat jej dobře nebude snadné a počet lidí, sledujících kód kontroly podpisu, CRDA je zřejmě dost malý. Luis by tedy rád kontrolu přesunul do jádra, kde by využívala stejného kódu jako modul loader. Tím by se snížilo množství kódu pro kontrolu podpisů a zvýšila jistota, že daný kus kódu pracuje tak, jak by měl.
V tomto případě neexistuje zařízení, které by převzalo zodpovědnost nad kontrolou podpisů. Jedná se o data, která užívá přímo jádro. Má li se ochránit před poškozenou CRDA databází, mělo by dělat kontrolu samo. Kód, který tuto kontrolu dělá, by mohl stejně dobře kontrolovat firmware. Takže zavést mechanismus kontroly firmware, který by zároveň kontroloval celistvost jiných souborů nahrávaných do jádra, dává vlastně trochu smysl.
Jakmile bude jasné, že funkce funguje jak bylo zamýšleno, nebude s jejím přidáním do jádra pravděpodobně žádný problém. Celkově se komunita staví k přidávání podobných mechanismů ověřování integrity spíše pozitivně, důležité ovšem je, aby rozhodnutí ohledně použití takové funkce, zůstalo v rukou uživatele. Distribuce mohou, ale nemusí zapnout kontrolu podpisu firmware, ale pro zájemce bude tato možnost k dispozici.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: