Před 25 lety, ve čtvrtek 29. dubna 1999, byla spuštěna služba "Úschovna".
Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Současné vývojové jádro je 4.12-rc4, vydané 4. června. Linus Torvalds je obvykle spokojen s tím, jak se věci mají: „Vše v cyklu 4.12 zůstává v klidu, i když ne až tak v klidu, jak to vypadalo začátkem týdne. Myslím, že dvě třetiny commitů přišly v pátek nebo o víkendu. Ale až na to načasování to vypadá vcelku normálně.“
Stabilní jádra: 4.11.4, 4.9.31, 4.4.71 a 3.18.56 vyšla 7. června.
Mark H. Weaver nám poslal upozornění, že stabilní vydání jádra s dlouhodobou podporou 4.1.40 je zranitelné CVE-2017-6074, což je lokální eskalace privilegií, která byla nahlášena už v únoru a v Linuxu se vyskytuje již přes deset let. Aktualizovaná verze od správce Sashi Levina byla očekávána brzy (vyšla 15. června).
Mnoho bajtů bylo v průběhu let vynaloženo na diskuze o kvalitách jaderného subsystému pro generování náhodných čísel. Jedna z nejčastěji se opakujících obav se týká systémů, které nemohou během procesu zavádění získat dostatečnou entropii, aby uspokojily požadavky na náhodnost dat. Nejnovější diskuze na toto téma začala poněkud ostře, ale může vést k postupnému zlepšení této oblasti.
Jason Donenfeld začal vlákno stížností, že /dev/urandom
při čtení z uživatelského prostoru vrátí data i v případě, kdy vnitřní jaderný zásobník entropie (entropy pool) nebyl ještě patřičně zaplněn. V takovém případě je teoreticky možné, že útočník bude předpovídat ony ne-až-tak-náhodné údaje, které budou vráceny. Donenfeld tvrdil, že /dev/urandom
by mělo prostě blokovat, dokud není zásobník entropie připraven, a odmítl zdůvodnění stávajícího chování: „Ano, ano, máte argumenty, proč to udržujete v patologickém stavu, ale stále se pletete a toto API je stále chyba.“
Chyba, nebo ne, jak upozornil Ted Ts'o, blokování /dev/random způsobuje, že distribuce jako Ubuntu nebo OpenWrt nenaběhnou. Tento druh chování se obvykle nazývá „regresí“ a regrese tohoto typu obvykle nejsou přípustné. Takže /dev/urandom si ponechá své současné chování. Ale tohle není myšlenka, kterou se Donenfeld původně snažil sdělit. Skutečný problém je, jak se ukázalo, získávání náhodných dat z jádra místo z uživatelského prostoru. To se dá udělat voláním:
void get_random_bytes(void *buf, int nbytes);
Tato funkce umístí nbytes bajtů náhodných dat do vyrovnávací paměti označené buf a stane se tak bez ohledu na to, zda je zásobník entropie zcela připraven. Takže opět je možné získat data, která nejsou opravdu náhodná. Vzhledem k tomu, že tato funkce je volána zevnitř jádra, mohou se tato volání uskutečnit brzy v procesu zavádění systému, takže riziko, že se setkáte s nedostatečnou entropií, je poměrně vysoké.
Tento problém samozřejmě není v komunitě jaderných vývojářů nový. V roce 2015 navrhl Stephan Mueller doplnění verze get_random_bytes(), která by blokovala, dokud nebude zásobník entropie připraven, bude-li to nutné. Tento nápad se ale dostal do problémů, když Herbert Xu poukázal, že to může vést k uváznutí (deadlock) – tedy typu náhodných událostí, které nebývají žádoucí. Místo toho tedy vzniklo rozhraní pro zpětné volání. Jaderný kód, který se chce ujistit, že dostává dobrá náhodná data, začíná vytvořením funkce zpětného volání a umístěním ukazatele na tuto funkci do struktury random_ready_callback:
struct random_ready_callback { struct list_head list; void (*func)(struct random_ready_callback *rdy); struct module *owner; };
Tato struktura je poté předána funkci add_random_ready_callback():
int add_random_ready_callback(struct random_ready_callback *rdy);
Když je subsystém náhodných čísel připraven, zavolá se předaná funkce zpětného volání. Přidáním další struktury (pravděpodobně pomocí dokončení), může volající kód vytvořit něco, co vypadá jako synchronní funkce pro získání náhodných dat.
Jak upozornil Donenfeld, toto rozhraní patří mezi těžkopádnější, s čímž může souviset skutečnost, že se v jádře volá jen na jednom místě. Navrhl, že by bylo smysluplné přidat synchronní rozhraní, které by se dalo použít aspoň v některých situacích, což by umožnilo opravit některá místa v jádře, u kterých hrozí použití nenáhodných dat. Ts'o souhlasil, že tento přístup by mohl dávat smysl:
Nebo možná pak pomůžeme zjistit, jaké procento zdrojů volání se dá opravit synchronním rozhraním, a opravit některé z nich prostě proto, abychom ukázali, že synchronní rozhraní opravdu funguje dobře.
Výsledkem byla řada patchů od Donenfelda, která přidala novou funkci:
int wait_for_random_bytes(bool is_interruptable, unsigned long timeout);
Jak může napovědět její název, wait_for_random_bytes() počká, až budou náhodná data dostupná. Je-li nastaven příznak if_interruptable, skončí funkce dříve (s chybovým kódem), pokud volající proces dostane signál. Parametr timeout jde použít k nastavení horní hranice na dobu, po kterou bude volání čekat. Ukázalo se ale, že tato funkce je poněkud navíc. Zejména Ts'o se o nápadu s časovou prodlevou vyjádřil skepticky, zeptal se: „Pokud používáte get_random_bytes() z bezpečnostních důvodů, zmizí příslušný bezpečnostní problém po 15 sekundách?“ Třetí verze sady patchů všechny argumenty wait_for_random_bytes() odstranila, takže všechna čekání jsou přerušitelná bez prodlevy.
Řada patchů dále přidala skupinu život zpříjemňujících funkcí, které kombinují čekání a skutečné získávání náhodných dat, včetně:
static inline int get_random_bytes_wait(void *buf, int nbytes);
Většina připomínek k této skupině patchů se v tomto okamžiku týká celkem malých drobností. Takže je pravděpodobné, že se některá její verze časem dostane do jádra, čímž se snad sníží riziko, že jádro bude používat nedostatečně náhodná data. Je tu ale ještě jeden aspekt, který se zdá zcela deterministický: dohady ohledně kvality jaderného subsystému náhodných čísel nejsou zdaleka u konce. To je koneckonců problém s náhodnými čísly: nikdy si nemůžeme být jisti, že jsou skutečně náhodná.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
audio-entropyd
, ale moc jsem si s tím nehrál, spíš jen zábava na půl odpoledne.
Taky je otázka, co brát jako náhodu - zda napětí při kterém se spustila lavina, nebo časy průchodu nulou - ty se dají detekovat snadněji.
Potom existují skutečné kvantové zdroje náhody (polopropustné zrcadlo jednotlivé fotony), ale to není na domácí bastlení a stejně se musí pořešit bias (žádné zrcadlo nemá přesně 50% odrazivost).
JDBC driver ceka na nahodna data z /dev/randomTohle ale zni jako blby kod v JDBC driveru. Pokud opravdu potrebuji /dev/random (tj nestaci jim /dev/urandom), pak si autori meli byt jasne vedomi ze /dev/random je opravdu pomalej a zaridit se podle toho (minimalne nejake warningy na konzoli...)
Linus 4.1.40 je zranitelný CVE-2017-6074Jsem čekal nějakej sociální engineering na Linuse a on to je jen překlep .