HollowByte je zranitelnost typu Denial of Service (DoS) v kryptografické knihovně OpenSSL. Útočník může odesíláním škodlivého payloadu o velikosti pouhých 11 bajtů zaplnit paměť serveru. OpenSSL před ověřením dat vyhradí nepřiměřený blok paměti (až 131 KB). Server pak čeká na data, která nepřišla. Zranitelnost je opravena ve verzích OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 a 3.0.21.
Ve španělské A Coruñě probíhá GUADEC 2026, tj. letošní konference vývojářů a uživatelů desktopového prostředí GNOME. Videozáznamy přednášek jsou k dispozici na YouTube.
Společnost Collabora ve spolupráci s Valve vyvíjí Holo Core, tj. port Arch Linuxu pro ARM64 procesory (AArch64), který bude pohánět VR headset Steam Frame. Pro testování Arch Linuxu pro AArch64 jsou k dispozici binární balíčky, zdrojové kódy i kontejner pro Docker nebo Podman.
Mikroprocesor Zilog Z80 byl oficiálně uveden na trh před 50 lety, tj. v červenci 1976. Výroba mikroprocesoru skončila v roce 2024.
Výzkumníci ze společnosti ESET objevili 11 zapomenutých UEFI shim zavaděčů, které byly podepsány společností Microsoft, a které umožňují útočníkům obejít ochranu UEFI Secure Boot na většině zařízení. Microsoft je zneplatnil (přidal jejich hash do databáze dbx) v rámci aktualizace Patch Tuesday dne 9. června 2026. Uživatelé Linuxu mohou databází aktualizovat pomocí LVFS. Ověřit zneplatnění zavaděčů lze pomocí skriptu uefi-dbx-audit. Jedná se o CVE-2026-8863 a CVE-2026-10797.
pico-usb-wifi je open source firmware pro Raspberry Pi Pico W, který jej promění v USB Wi-Fi adaptér. Po připojení k počítači se objeví jako zařízení USB CDC-NCM.
Americká společnost Google ze skupiny Alphabet bude muset podle nových požadavků Evropské unie umožnit společnosti OpenAI i dalším konkurentům v oblasti umělé inteligence (AI) a internetových vyhledávačů přístup ke svým službám. Ve svém rozhodnutí o tom včera informovala Evropská komise (EK). Opatření má zajistit dodržování pravidel, jejichž cílem je omezit v EU tržní sílu velkých technologických firem. Google s tím nesouhlasí.
… více »Nové verze webových prohlížečů Chrome a Firefox jsou vydávány každé 4 týdny. Aktuální verze Chrome je 150. Aktuální verze Firefoxu je 152. V březnu bylo oznámeno, že od září přejde Chrome na dvoutýdenní cyklus vydávání verzí. To by znamenalo, že Chrome v číslování verzí Firefox brzy přeskočí. Vývojáři Firefoxu proto také od září přecházejí na dvoutýdenní cyklus vydávání verzí. :-)
Microsoft Comic Chat (Wikipedie), tj. grafický IRC klient z devadesátek, který převáděl konverzace na IRC do podoby komiksových panelů, a který zpopularizoval font Comic Sans, je dnešním dnem open source. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Byla vydána (𝕏) nová verze 26.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 26.7 je Xenial Xenops. Přehled novinek v příspěvku na fóru.
OpenBSD 5.5 vyjde 1. května. Oficiální píseň je už ale k dispozici. Nejnovější hudební hit z produkce OpenBSD je věnován problému roku 2038: Řekněte mi doktore, jaký bude rok, 1901 nebo 2038? OpenBSD 5.5 přijde s 64bitovým time_t na všech platformách. Píseň s názvem Wrap in Time lze stáhnout ve formátech MP3 a OGG.
Tiskni
Sdílej:
16.4.2014 10:19
Petr Tomášek | skóre: 39
| blog: Vejšplechty
16.4.2014 12:37
Petr Tomášek | skóre: 39
| blog: Vejšplechty
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
time_t ať si upravjí, jak se jim zlíbí: pokud jim to nic nerozbije, tak proč ne...
16.4.2014 13:03
Punny | skóre: 28
| Praha
16.4.2014 13:30
Prcek | skóre: 43
| Jindřichův Hradec / Brno
Zoufalé. Kdyby raději přišli s kernelem bez Giant Locku. Na 64-bitový time_t je čas, zatímco kernel s Giant Lockem do 21. století nepatří. Totéž platí o naprosto zastaralém zabezpečení.
OpenBSD's security model is more about -- as I phrase it -- keeping the bastards out, not controlling them (or hoping to control them) after they are in. Making life difficult for attackers once they get into your system is usually not going to be overly productive, and usually makes administration of the system much more difficult, which often creates NEW security problems of their own. While people like to talk about "Defense in depth" -- and it is not a bad idea -- your best goal is to keep the bastards on the outside of your systems, as once they are in, they can utilize anything you don't have perfectly bolted down to accomplish their goals (and yes, that statement puts me opposite a lot of people making a lot of money chasing down bad guys AFTER they inflitrate systems). In the Real World: First thing most people do on an SElinux system is disable SELinux. At that point, all the RBAC "features" are now just pure glossy advertising -- worthless. For fear of breaking things, the Linux people have chosen to put a big on-off switch on SELinux...and so given a choice between fixing applications and turning off the switch...people just turn off the switch. ANY claimed benefits of SELinux are ONLY there if it is enabled and used properly.
REAL security is not a list of features, even if used. The OS is just the tip of the security iceberg...or maybe more accurately, the base of it. You don't typically run an OS to run an OS. You run the OS to run applications, and if those applications are poorly written or poorly designed, there are limits to how much (if at all) the OS can help. The best OpenBSD can do is give you a good starting foundation.Par reakci na uvadeny "odborny" rozbor vedouci k nutnosti ACL v systemu: Sometimes the "add-on" security enhancements directly weaken system security ACL, SELinux velmi trefne
In the Real World: First thing most people do on an SElinux system is disable SELinux.
Tohle je nějaká fikce. Nikdy, ani jednou a ani omylem mě nenapadlo vypnout SELinux. Proč bych to dělal? To by pak opravdu zabezpečení spadlo skoro až na úroveň OpenBSD. Pokud někdo vypne SELinux, dobře mu tak.
Je vtipné, jak se advokáti OpenBSD zoufale snaží obhájit absenci klíčové funkcionality, která v moderním systému prostě má být, v ostatních BSD variantách většinou je a pouze OpenBSD ji ze zásady nemá. Nejhorší případ je ovšem ten Giant Lock. Je úplně jedno, že to tu a tam funguje dobře i s Giant Lockem. Na router s několika 10 Gb/s síťovkami to zkrátka nemusí stačit, přestože každý jiný systém s rozumným (tj. ne tak extrémně blokujícím) kernelem by totéž zvládl v pohodě.
Ono to SMP praci zvlada pomerne dost dobre, ze treba firewall vyuzije jedno CPU a I presto zvlada to na co jinde potrebuji hromadu CPU je na zamysleni v tech jinych projektech.
Tohle by chtělo odkaz na konkrétní benchmark, který to dokazuje, nebo zkrátka nějaké rozumné podklady pro taková tvrzení. SMP práci zvládá OpenBSD „dobře“ pouze v userspace. Jakmile dojde na cokoliv, co by měl dělat kernel, například složitější routování s fitrováním a s několika sítovými kartami, pokročilé souborové systémy (které OpenBSD nemá), použitelnou virtualizaci (kterou OpenBSD nemá) nebo softwarový RAID (který OpenBSD téměř nemá), v podstatě všechny ostatní systémy (Linux, FreeBSD, Illumos/OpenIndiana) natrhnou OpenBSD prdel už jen tím, že příslušnou funkcionalitu zkrátka mají, pokud ne přímo výkonem. Ovšem ani u toho výkonu bych si nebyl tak jistý, že má OpenBSD navrch a že je důvodem k zamyšlení pro ostatní projekty. Ještě jsem neviděl benchmark, ve kterém by OpenBSD porazilo Linux, ať už na jednoprocesoru nebo na SMP.
Nikdy, ani jednou a ani omylem mě nenapadlo vypnout SELinux.Co napadlo a nenapadlo tebe není úplně relevantní v tvrzení o "most people"
Na router s několika 10 Gb/s síťovkami to zkrátka nemusí stačit, přestože každý jiný systém s rozumným (tj. ne tak extrémně blokujícím) kernelem by totéž zvládl v pohodě.. U klientu bezi Cisca i vlastni routery nad OpenBSD a nezaznamenali jsme zatim zadne vykonnostni problemy ani pri zatezovych testech. Na extra vytizenych uzlech jsou Junpery, ale ten rozdil je v jednotkach procent.
Jasně, kdo má někde na půdě nebo ve sklepě starý jednoprocesor, ten asi ví, co „to“ dokáže.
Je obrovský rozdíl v tom, co stačí pro dané konkrétní nasazení a čeho lze v nejlepším případě na daném hardwaru dosáhnout. Mícháte tu nějak podivně obojí dohromady.
Jasně, údajně jste nezaznamenali výkonnostní problémy při nějakých blíže nedefinovaných zátěžových testech. A co z toho vyplývá? Řekl bych, že vůbec nic. Kdyby například výstupem toho zátěžového testu byl maximální dosažený throughput a OpenBSD by na stejném hardwaru dosáhlo výsledků srovnatelných s Linuxem, pak by celé tvrzení bylo relevantní pro tuto diskusi. Takhle to ale nedává smysl. Říkáte, že nějakému klientovi někdy někde stačilo OpenBSD. Vůbec neříkáte, jak jste síť testovali, jaký měla throughput, jestli se opravdu podařilo využít maximální dosažitelný bandwidth a tak dále.
Upřímně řečeno, jedna věc je jasná: Giant Lock vždy prohraje. Že OpenBSD někdy jednou někomu stačilo, tomu rád věřím, ale jakéhokoliv moderního hardware je pro něj škoda. Doba jednoprocesorů už je pryč.
Zatimco na OpenBSD mam vykon bez tech pruseru okolo. A ze nejaky system je treba o 10% rychlejsi mne absolutne nezajima, kdyz kvuli tomu ma mnohem slozitejsi administraci, mnohem vice nutnych aktualizaci a downtime a casteji se na nem neco pokazi nebo podporuje kdejakou blbost, ale kazda nedotazena.
Benchmark...... Tohle slovo mne vzdy rozesmeje. Napr. Phoronix je ma skvele, takove ty fajne, ktere rozebrali lidi okolo Dtrace a ukazali, ze treba misto CPU to meri disk a podobne vylomeniny. Benchmark je spousta uzasne teorie, ale jediny benchmark, ktery ma cenu je ten, ktery meri realne nasazeni systemu a ne nejakou teorii vycucanou z prstu. A takovych jsem videl jen par, protoze drtiva vetsina firem je bud za a) nechce platit, protoze jsou opravdu narocne na cas a prostredky nebo za b) by se ukazalo, ze pravda je na druhe strane. Tak se to radeji dela stylem 8 z 10 doporucuje.... :D
If you think micro benchmarks are worth anything you have a micro
understanding of the problem. -- Marco Peereboom
The biggest flaw with all those great benchmark articles is that their
often flawed and the people behind them are biased to show whatever they
like to prove. In the end many of fefe's test programs did not actually
measure what he assumed they would. -- Claudio Jeker
In the end it boils down to measuring the different OS on the hardware
you will use for the task they should fullfill, nothing else matters in
the end.
A obrazek na zaver. Od Netflix, ktery ".... uses if_lagg in their CDN – 32% of North American Traffic flowing through driver based on trunk(4) . Interne pouzivaji FreeBSD, ktere ma v sobe i Dtrace, to vzniklo v Sun, jeho autor pak delal v Joyent kde to dost posunul pro SmartOS, Illumos a FreeBSD a ed presel do Netflix. Spoustu zajimaveho se deje a Google (ten uz 3 roky po sobe jako top), Facebook a dalsi velci hraci nejsou jen tak pro nic za nic sponzori OpenBSD
18.4.2014 20:21
Ruža Becelin | skóre: 40
| blog: RuzaBecelinBlog
static const char rnd_seed[] = "string to make the random number generator think it has entropy";
What a benchmark !!! Testing sci-fi instead of reality :D
Ale nekterym lidem to proste nevysvetlite. Kde chybi rozum, nahrazuji ho pocity a symboly, se kterymi by identifikovali svoje predstavy.
Btw. hlavne po udalostech z posledni doby nechapu jak nekdo dobrovolne nasadi SELinux. Jedine ze by si ho sam zauditoval, ale u tak komplexniho bazmeku to povazuju za prakticky nemozne. A pak jeste hlidat updaty.
18.4.2014 11:05
pavlix | skóre: 54
| blog: pavlix
18.4.2014 21:52
Jendа | skóre: 78
| blog: Jenda
| JO70FB
18.4.2014 22:32
Jendа | skóre: 78
| blog: Jenda
| JO70FB
m. (strana 122 a dál) Tomuto lze zabránit buď volením m náhodně (tento postup se již v praxi opakovaně neosvědčil) nebo použitím digestu podepisované zprávy jako m (nebo jeho zamixováním do entropy poolu, což je nejspíš to, co se odstraněný kód snaží dělat - předpokládám, že dgst je to, co jdeme podepisovat). To vede na deterministic dsa signature. Po aplikování diskutovaného patche podle mě hrozí leaknutí klíče skrze stejná m, pokud se nepodaří dostatek entropie nasbírat odjinud.
Tomuto lze zabránit buď volením m náhodně (tento postup se již v praxi opakovaně neosvědčil)V obou případech šlo o chybu v PRNG. Nejsem znalec OpenBSD, ale myslím, že veškeré jejich úpravy stojí právě na tom, že mají kvalitní a otestovaný PRNG.
nebo použitím digestu podepisované zprávy jako m (nebo jeho zamixováním do entropy poolu, což je nejspíš to, co se odstraněný kód snaží dělat - předpokládám, že dgst je to, co jdeme podepisovat).Je už sice skoro půlnoc, ale řekl bych, že mixováním dgst do m ztráciš právě tu náhodnost, proto ta úprava. Pokud nemáš dostatečnou entropii, jak ti pomůže zamíchat do ní známou hodnotu?
18.4.2014 23:31
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Nejsem znalec OpenBSD, ale myslím, že veškeré jejich úpravy stojí právě na tom, že mají kvalitní a otestovaný PRNG.Nevěřím :)
Je už sice skoro půlnoc, ale řekl bych, že mixováním dgst do m ztráciš právě tu náhodnost, proto ta úprava. Pokud nemáš dostatečnou entropii, jak ti pomůže zamíchat do ní známou hodnotu?Jenže mně nejde o to, aby
m byla náhodná, nepredikovatelná nebo tak něco - mně jde o to, aby byla pro každou různou zprávu jiná.
myslím, že veškeré jejich úpravy stojí právě na tom, že mají kvalitní a otestovaný PRNG.No, a já zase myslím, že veškeré jejich úpravy jsou k hovnu, protože podobným stylem se prostě nedá pracovat. K čemu mi bude forknutá knihovna, která spoléhá na specifické implementace něčeho v OpenBSD? Jako vyházet podporu všech OS, co se mi prostě nelíbí, a přepsat to tak, že to bude (možná) fungovat pouze v OS, který používá (když budu optimistický) tak pár desítek tisíc lidí, to je opravdu úžasný přístup k vylepšování něčeho, co má být univerzálně použitelné. No, hlavně že si TdR užil několika orgasmů při sepisování těch commit messages.
19.4.2014 12:55
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Ty dva odkazy na PRNG faily se týkají generování klíčů.Ne, ten bitcoinový je leak klíče přes podepsání dvou transakcí. Btw. zajímalo by mě, jestli měl Debianí bug taky vliv na DSA podepisování, moc se o tom nemluví.
RAND_seed is now DEPRECATEDTo bude slušnej matroš, patrně rovnou z Amstru.