Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
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ů.
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