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.
MojeFedora.cz informuje, že bylo oficiálně oznámeno vydání Fedory 29. Ve finální verzi vycházejí tři edice: Workstation pro desktopové, Server pro serverové a Atomic pro cloudové nasazení. Vedle nich jsou k dispozici také alternativní desktopy, např. KDE Plasma (spiny Xfce a LXDE byly kvůli chybám odloženy) a k tomu laby – upravené vydání Fedory například pro designery, robotiku, vědecké použití atd. Stahovat lze z Get Fedora.
Tiskni
Sdílej:
30.10.2018 20:09
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
31.10.2018 03:05
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
No, spíš je to takové objevení Ameriky: aplikace, které potřebují pracovat s vašimi daty, nejsou 100% sandboxované a světe div se mají k těm datům přístup.Pokud máš sandbox s přístupem do
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
30.10.2018 16:55
30.10.2018 17:22
$HOME a ne nějaké omezené podsložky, tak nemáš sandbox.
Pozor, aplikace třetí strany může mít nezáplatovanou díru.Ne jen ta aplikace, ale celý stack, který se ti normálně na linuxu updatuje. Flatpak by měl mít podtitul „to nejhorší z uživatelského zážitku distribuce windows aplikací nyní i ve vašem linuxu“. Myslel jsem, že ta doba kdy jak idiot musím googlit abych si stáhl nějaký program a pak lézt na nějaký obskurní web a stahovat tam pofidérní binárky je dávno pryč. Ale ne, teď se to zase vydává za krok vpřed.
A "Flatpak, který instalujete s právy roota, může získat práva roota" (což je mimochodem naprosto integrální vlastnost drtivé většiny balíčkovacích systémů) si dovolili opravit jenom jako minor security issue :)Tady jde o princip - flatpak je prezentovaný jako nejlepší vynález, jako nějaký způsob záchrany distribuce aplikací v linuxovém světě. Přitom je to sračka, jak z uživatelského hlediska*, tak z hlediska správce systému. Jediný kdo z toho má nějaké výhody je tvůrce aplikace, který se tak nenadře při balení, což je ovšem dneska podle mého názoru relativně automatizovatelný problém.
Jediný kdo z toho má nějaké výhody je tvůrce aplikace, který se tak nenadře při balení, což je ovšem dneska podle mého názoru relativně automatizovatelný problém.Tak automatizovaný systém, který by mi umožnil produkovat s dostatečnou zárukou balíčky pro většinu mainstreamových distribucí, aniž bych to musel na každé distribuci ručně testovat a pravidelně sledovat, zda se něco kvůli aktualizovaným zavistlostem nerebuildnulo bych chtěl vidět. Klidně bych to používal místo Flatpaku, kdyby něco podobného existovalo.
1.11.2018 22:51
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
)
macOS includes a low-level command-line interface to the OpenSSL open-source cryptography toolkit; this interface is not available in iOS.
Although OpenSSL is commonly used in the open source community, it doesn’t provide a stable API from version to version. For this reason, the programmatic interface to OpenSSL is deprecated in macOS and is not provided in iOS. Use of the Apple-provided OpenSSL libraries by apps is strongly discouraged.
Pokud tedy chci jako vývojář napsat něco, co může fungovat stylem "fire and forget", mám tu možnost a mít ji pravděpodobně dost dlouho budu.Protoze Windows nerozbiji ABI. Ale nejsem si teda jisty jestli bys na Windows 10 pustil aplikaci treba pro Windows 95 (to je tech 25 let). Ze stejneho duvodu se mohl stal linux standardem pro kontejnery, we do not break userspace.
31.10.2018 23:59
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Flatpak je pragmatické řešení problému, který "opravdové" řešení prostě nemá.ABI backwards compatibility. Nedavno jsem tady posilal odkaz na mnoho let stary rozhovor se zakladatelem Gnome, ktery presel na OS X, a presne toto citoval jako duvod proc Linux prohral bitvu o desktop. Flatpak je jen dalsi z polofunkcnich workaround staleho rozbijeni ABI* zakladnich gui/desktop knihoven, je opravdu tak těžké ho takto vnímat a podle toho jej v praxi (ne)nasazovat?
To má Miguel DeIcaza (předpokládám, že je řeč o něm) z velké části pravdu. Vtipné je, že kdykoliv s tím v Linuxovém ekosystému začne někdo něco dělat, snese se na něj vlna hejtů o tom, jak je to špatné a že "teď" je to vyřešené vlastně správně. Udržet dlouhodobě stabilní nějaké netriviální API je jakž takž možné jen v značně homogenním prostření, které spravuje a ovládá jedna entita. Na druhou stranu tady máme svět FOSSu, kde si může z definice každý dělat co chce a jak chce. Skloubit dohromady striktně plánovaný vývoj a hejhurá bastlení garážových hackerů prostě nejde...Flatpak je pragmatické řešení problému, který "opravdové" řešení prostě nemá.ABI backwards compatibility. Nedavno jsem tady posilal odkaz na mnoho let stary rozhovor se zakladatelem Gnome, ktery presel na OS X, a presne toto citoval jako duvod proc Linux prohral bitvu o desktop.
Flatpak je jen dalsi z polofunkcnich workaround staleho rozbijeni ABI* zakladnich gui/desktop knihoven, je opravdu tak těžké ho takto vnímat a podle toho jej v praxi (ne)nasazovat?Kvalifikátor stupně funkčnosti nechť si dosadí každý jaký chce. Je-li k dispozici objektivně lepší řešení, sem s ním. V opačném případě zůstanu u Flatpaku, který se aktivně vyvíjí, má backing velké firmy a v principu rozumný návrh.
Vtipné je, že kdykoliv s tím v Linuxovém ekosystému začne někdo něco dělat, snese se na něj vlna hejtů o tom, jak je to špatné a že "teď" je to vyřešené vlastně správněNevsiml jsem si, ze by se s tim snazil nekdo neco delat. Cely desktop stack kompletne od gtk (vcetne) ma pod kontrolou Red Hat (brzy IBM) a za rozbijeni ABI schytava pouze kritiku uz radu let, je o tom cela sekce na wikipedii.
Kvalifikátor stupně funkčnosti nechť si dosadí každý jaký chce. Je-li k dispozici objektivně lepší řešení, sem s ním. V opačném případě zůstanu u Flatpaku, který se aktivně vyvíjí, má backing velké firmy a v principu rozumný návrh.Pouzivas QT5 a qt ABI kompatibilitu jen tak nerozbiji, takze i kdybys to releasnul jako "blby" tarball s dynamickou zavislosti na QT knihovnach (prekompilovat proti nejstarsimu QT5, ktere chces podporovat) a ty special knihovny zabundloval (jak je to s icu nevim), tak to bude mit narozdil od flatpaku nasledujici vyhody - bezpecnostni updaty zavislosti, lepsi integrace (fonty, temata,..), bude fungovat na vice distribucich (qt5.2 je uz v ubuntu 14.04 LTS) a uzivatel nebude mit falesny pocit bezpecnosti.
Pouzivas QT5 a qt ABI kompatibilitu jen tak nerozbiji, takze i kdybys to releasnul jako "blby" tarball s dynamickou zavislosti na QT knihovnach (prekompilovat proti nejstarsimu QT5, ktere chces podporovat) a ty special knihovny zabundloval (jak je to s icu nevim), tak to bude mit narozdil od flatpaku nasledujici vyhody - bezpecnostni updaty zavislosti, lepsi integrace (fonty, temata,..), bude fungovat na vice distribucich (qt5.2 je uz v ubuntu 14.04 LTS) a uzivatel nebude mit falesny pocit bezpecnosti.Úplně stejně jsem dřív uvažoval taky a nějaký SW jsem jako všechnotarbally distribuoval. Měl jsem kvůli tomu virtualizované Ubuntu 12.04 v 32 a 64 bit vezích, Qtčka jsem bundloval, protože mám hard dep na verzi 5.6 a vyrobit ten tarball s každým novým releasem byl komparativně větší voser, než pustit skriptík na sestavení flatpaků. Jednou jsem cca rok starý tarball vzal a zkusil pustit na v té době aktuálním Archu. Nespustilo se samozřejmě nic, protože se někde změnilo ABI libgfortran, na které jsem nepřímo závisel. Od té doby jsem začal balit Flatpakem. Moc zkušeností s dlouhodobou funkčností ještě nemám ale zatím se nic přímo nerozbilo. Napadá mě akorát, že na Fedoře otevíral Flatpak ještě okolo verze 1.0.0 Gtkčkové load/save dialogy, což mělo v případě interakce s Qt appkou dost bizarní vliv na funčnost (kromě toho, že to vypadalo fakt dementně). Od nějaké aktualizace už je to okay. Zvláštní je, že na Archu to chodilo správně vždycky...
Úplně stejně jsem dřív uvažoval taky a nějaký SW jsem jako všechnotarbally distribuoval. Qtčka jsem bundloval, protože mám hard dep na verzi 5.6. Nespustilo se samozřejmě nic, protože se někde změnilo ABI libgfortran, na které jsem nepřímo záviselMuzu ti poslat build vimu s dynamickymi zavislostmi (ale bundlovanym pythonem2.7 kvuli rhel5), ktery funguje spravne (a to diky dynamickym zavislotem!) na vsem od rhel5 po nejnovejsi debian. Dynamicke zavislosti musi byt pouze na knihovny se stabilnim ABI, vse ostatni je bohuzel nutne bundlovat. S flatpakem bundlujes vse a tim si vytvaris nove slozite problemy. Ale ze zrovna libgfortran nebude mit stabilni ABI ... to bych asi rozmlatil klavesnici :). Z toho co pises chapu ze si frustrovany z neustaleho rozbijeni ABI kompatibility na linuxu a si pak rad za cokoliv co bude aspon nejak fungovat a tolerujes pak klidne i rozhozene file dialogy. V te frustraci z rozbiteho ABI v userlandu na linuxu se shodneme, v narocich na kvalitu pripadneho reseni ne. Staci si z flathubu nainstalovat treba Octave (nebo jinou QT aplikaci) a najednou pouziva jine fonty nez zbytek systemu (zkouseno v gnome, bez flatpaku se integruje spravne) - pro me je tohle neprijatelne, nemluve o bezpecnosti a hlavne - jaktoze vsechny tyto "known limitations" nejsou nikde zdokumentovane a pokud se o nich clovek zmini, tak zacnou flatpak vyvojari akorat rvat ze si "hater"? Toto receno, chapu tvoji frustaci a to ze se pak spokojis s jakymkoliv resenim. Shodneme se na tom, ze opravdove reseni by bylo stabilni ABI desktop stacku?
Shodneme se na tom, ze opravdove reseni by bylo stabilni ABI desktop stacku?Ano stabilni ABI na linux desktopu jen tak nebude, ale to nam prece poskytuji stable/LTS distribuce. Proc teda v tom chrootu nepoustet misto zcela novych runtimes + bundle jiz existujici stable/LTS ditribuci? Tak by taky fungoval jeden balicek "vsude" (diky tomu ze ma kernel dekady stabilni ABI a zbytek bude v chrootu uplne stejne jako s flatpakem); nebude potreba spravovat nove balicky (flatpak runtimes) a backporty uz pro nas nekdo dela, navic budou fungovat automaticke updaty zavislosti a bude jednodusi integrace, napr. ten fontconfig by stacilo nastavit dvakrat (jednou v host systemu, jedno v chroot distru) misto N ruznych runtimes. Taky bych se nebal pouzit knihovny mimo chrootu v pripadech kdy to dava smysl (napr. libGL.so).
30.10.2018 23:04