Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
Byla vydána nová verze 10.8 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyl balíček DietPi WireGuard.
Oslavte vydání openSUSE Leap 16.1 s námi v Praze! Ve středu 4. listopadu 2026 (den po vydání Leapu 16.1) vás zveme na malou oslavu vydání openSUSE Leap 16.1 do pražské kanceláře SUSE. Připravili jsme pro vás dvě krátké přednášky: … více »
Dle plánu bylo PHP vydáno v nových verzích 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Opraveny jsou kritické zranitelnosti CVE-2026-109618 a CVE-2026-109619 aneb PHP2Shell.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-2.1 a 24.04-1.5. S opravou kritických zranitelností.
Jakmile jste vevnitř, upravte soubor '/etc/initramfs-tools/modules' přidáním následujících řádek, aby měl initrd k dispozici patřičné moduly pro připojení šifrovaného oddílu:Poslední rok tohle minimálně v Debianu a Ubuntu dělá update-initramfs automaticky.aes-i586 xts dm-crypt dm-mod sha256
Tenhle text je tady sice OT, ale přišel mi zajímavý.Díky za link, na to jsem kupodivu při "průzkumu trhu" před psaním svého článku nenarazil.
Teoreticky by šlo použít i gparted, ale netuším jak v něm nastavit typ oddílu na LLVM.Strýček Google mi na otázku "parted type lvm" vyhodil hned na prvním místě tenhle odkaz, kde je následující příklad:
For example: (parted) mkpart primary ext2 0 4000 (parted) set 1 lvm onCo jsem koukal na výstup partedu na mém notebooku, opravdu tam není lvm zadané jako typ filesystemu, nýbrž jako flag (mimochodem, stejně tomu je třeba i u RAIDu):
Číslo Začátek Konec Velikost Typ Systém souborů Přepínače 1 32,3kB 37,7GB 37,7GB primary lvm 3 37,7GB 500GB 462GB extended 5 37,7GB 37,9GB 148MB logical ext3 6 37,9GB 500GB 462GB logical lvm
Popravdě, jsem docela zklamaný - samostatný boot oddíl, nuda.Praví paranoici můžou mít /boot samozřejmě na flashdisku, který nespouští z očí, stačí ho jen překopírovat a smazat ten původní.
To už mi připadá, že je lepší a efektivnějši šifrovat jenom /home..Efektivnější z hlediska rychlosti jistě ano, ale jak už jsi psal - leaky probíhají přes /tmp a hlavně swap. Ne teoreticky, ale zcela prakticky. Navíc díky tomu že reálné umístění souborů není vždy stejné a smazané soubory se tak dají obnovovat, i když jsou přepsány, je možné z disku vyhrabat lecos. Jinak ten rychlostní propad není tak strašný, naopak prakticky nepostřehnutelný. Co může víc vadit je zatížení procesoru, který při větších diskových operacích jede na plný koule, protože má plné ruce práce s (de)šifrováním. Pokud máš dvě a více jader, tak to však není problém. Časem bych rád přidal můj script, který mě upozorňuje na změny v /boot, takže i kdyby ho někdo napadl v offline režimu, měl bych se o tom dozvědět. Zatím však není moc vytuněný a tak ho prezentovat nebudu.
Praví paranoici můžou mít /boot samozřejmě na flashdisku, který nespouští z očí, stačí ho jen překopírovat a smazat ten původní.To už je snazší ti tam narvat HW keylogger, než se štvát s patchováním initramdisku. Nebo použít legendární pilník (na tebe) :).
leaky probíhají přes /tmp a hlavně swapUpřímně já bych nerad ještě
/var/log/ (pohyb notebooku za posledních pár měsíců - podle SSID) a do /root/ taky občas něco uložím.
To už je snazší ti tam narvat HW keylogger, než se štvát s patchováním initramdisku.Spoléhám na to, že HW keyloggeru bych si u notebookové klávesnice všiml, to by muselo být něco fakt hodně speciálního a drahého, aby se to tam vešlo (navíc je tam podstatně víc datových vodičů, protože na té klávesnici imho není řadič) a zas tak velká ryba nejsem. Jinak tohle může čistě teoreticky řešit identifikační karta s čipem. Všiml jsem si, že na pracáku jí má ta pracovnice vždy zasunutou do klávesnice ze strany, vcelku by mě zajímaly podrobnosti.
Nebo použít legendární pilník (na tebe) :).Jo, to by zabralo. Jediné řešení co mě napadlo jsou nějaké autodestrukční mechanismy (stačí umazat prvních pár KB kde jsou zašifrované klíče) po dvou špatných heslech, nebo tak něco. Jinak primárně mi jde spíš o ukradení notebooku, v případě že by to heslo někdo fakt hodně chtěl by ho samozřejmě dostal, protože zas takovej drsňák abych kvůli svému systému nechal zabít svojí rodinu, popřípadě se mučit fakt nejsem. Teď mě ještě napadá že by šlo použít cosi jako DM-steg.
Jediné řešení co mě napadlo jsou nějaké autodestrukční mechanismy (stačí umazat prvních pár KB kde jsou zašifrované klíče) po dvou špatných heslech, nebo tak něco.K tomu potřebuješ HW podporu.
Teď mě ještě napadá že by šlo použít cosi jako DM-steg.Vždycky to nastav tak, abys mohl dokázat, že „teď jsem už opravdu rozšifroval všechno“. Třeba vyplň volné místo nulama nebo tak něco (pravda, co s těmi 10 GB, co jsem navzorkoval nekvalitním AD převodníkem, a tak je v tom hromada bílého šumu?). Ušetříš si tím zbytečné zalévání, kdy už jsi jim stejně všechno řekl, ale oni si myslí, že tam ještě něco je.
/usr/sbin aircrack…
A co ~root/.bash_history?
Tiskni
Sdílej: