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.
Dobrý den. Mám USB bluetooth adaptér MSI Star Key 2.0 v2 a telefon Sharp GX33. Distro Debian sid, kernel 2.6.22-3-amd64. Nainstaloval jsem všechny dostupné balíčky kolem Bluez a Obex. Spárování funguje, z telefonu jdou do počítače nahrávat soubory (konkrétně obrázky z foťáku, jiné tam nemám). Spojení ale nikdy nevydrží dlouho, když chci znova komunikovat třeba po minutě, musím telefon znovu spárovat (přitom "čas odpojení" v mobilu mám nastaven na hodinu).
Nicméně Wammu telefon vůbec nenajde. Taky se nevytváří zařízení /dev/rfcomm0 ani žádné podobné, takže v KMobileTools nemám co zadat. Když napíšu hcitool scan, telefon se někdy objeví a někdy ne (!), obdobně v Konqueroru když zadám bluetooth:/ tak telefon tam někdy vidět je, někdy ne (někdy jsou tam vidět i jiné telefony, asi od sousedů). Předpokládám, že USB dongle je v pořádku:
$ hcitool dev
Devices:
hci0 00:11:67:8D:5E:D1
$ /usr/sbin/hciconfig -a
hci0: Type: USB
BD Address: 00:11:67:8D:5E:D1 ACL MTU: 1021:8 SCO MTU: 48:10
UP RUNNING PSCAN
RX bytes:19421 acl:77 sco:0 events:666 errors:0
TX bytes:4059 acl:73 sco:0 commands:237 errors:0
Features: 0xff 0xfe 0x8d 0x3e 0x88 0x19 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'rb1j110-0'
Class: 0x180100
Service Classes: Capturing, Object Transfer
Device Class: Computer, Uncategorized
HCI Ver: 2.0 (0x3) HCI Rev: 0x2c6 LMP Ver: 2.0 (0x3) LMP Subver: 0x2c6
Manufacturer: Integrated System Solution Corp. (57)
Možná to nějak souvisí s absencí balíčku bluez-sdp (aptitude píše "K balíku bluez-sdp nebyla nalezena kandidátská verze").
Nevíte někdo, jak to řešit? Nebo aspoň, jestli je to jeden problém, nebo víc problémů? Díky.
ad rfcomm - po spusteni "rfcomm bind all" se zarizeni vytvori?
nevytvoří, příkaz nevypíše žádnou chybu, ale nic se nevytvoří.
ad nestabilita - zkusil bych adapter vytahnout a zase zasunout
zkusil jsem to a zatím to vypadá, že hcitool scan teď vidí telefon při každém pokusu, i v konqueroru je přes bluetooth:/ vidět pokaždé, tak uvidím, jestli to vydrží.
stalo za to, vedet, co je to za telefon
je to Sharp GX33, už jsem to psal výše:) pravda, v databázi telefonů Gammu je GX-20 jako "not supported", zato GX17 jako funkční (ale jen s ovladačem at115200, čili asi přes kabel).
když dám ve Wammu autodetekci telefonu, tak se zastaví na "Vyhledávám zařízení Bluetooth pomocí PyBluez" a dál nedojde.. když to zkusím ručně, nabídne mi adresu telefonu (tu co najde hcitool scan), ale když ji vyberu, řekne, že zařízení neexistuje..
no a v KMobileTools nemám jak zadat to zařízení, když ho v /dev/ nemám..
Tak jsem to nakonec (skoro úplně) vyřešil.. ve Wammu bylo potřeba nastavit ovladač "bluerfat" místo "blueat" (s obexem si ani neškrtne..), načež se zdařil import kontaktů, hovorů i sms, takže jsem spokojen.
S tou stabilitou spojení je to pořád takové zvláštní.. když na telefon hrabe Wammu, ikonka bluetooth v systray KDE svítí stále modře, jinak ale po chvilce zhasne a telefon se pak musí znova spárovat (nastavení času odpojení na "neomezeně" na to nemělo vliv) .. to mě zase tolik netrápí, protože stejně většinou nedělám s telefonem víc věcí po sobě; předpokládám, že data z něj budu stahovat vždy jednou za čas a přímo během přenosu se to nikdy nepřeruší, takže to se nějak zvládne. (Napadlo mě, že signál může být slabý kvůli kovové konstrukci stolu, pod nímž je PC umístěno, jakože to je taková Faradayova klec:), ale to už nesouvisí s Linuxem.)
No jen tedy zbývá nemožnost využít KMobileTools kvůli absenci zařízení v /dev/.. škoda, že se KMobileTools neumí spojit přes tu MAC adresu (nebo co to je), jako Wammu.
rfcomm bind 0 00:1C:EE:19:5E:5B 1" (00:1C:EE:19:5E:5B je MAC adresa telefonu, kterou vypíše "hcitool scan"). Vytvořilo se zařízení /dev/rfcomm0 a to jsem pak zadal v KMobileTools. Nicméně tam je problém, že mnoho SMS to stáhne nějak zmršeně.. místo většiny znaků jsou tam nějaké řecké znaky, nechápu proč (a zkoušel jsem změnit kódování z 8859-1 na GSM i ASCII, ani jedno nepomohlo.. a nakonec KMobileTools spadly a bylo třeba je zabít). Ale ve Wammu jsou všechny SMS v pořádku (jen mně trochu štve, že Wammu je jediná GUI aplikace, kterou používám a není Qt:) ).
Tiskni
Sdílej: