Byla vydána verze 1.91.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Ministerstvo průmyslu a obchodu vyhlásilo druhou veřejnou soutěž v programu TWIST, který podporuje výzkum, vývoj a využití umělé inteligence v podnikání. Firmy mohou získat až 30 milionů korun na jeden projekt zaměřený na nové produkty či inovaci podnikových procesů. Návrhy projektů lze podávat od 31. října do 17. prosince 2025. Celková alokace výzvy činí 800 milionů korun.
Google v srpnu oznámil, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Iniciativa Keep Android Open se to snaží zvrátit. Podepsat lze otevřený dopis adresovaný Googlu nebo petici na Change.org.
Byla vydána nová verze 18 integrovaného vývojového prostředí (IDE) Qt Creator. S podporou Development Containers. Podrobný přehled novinek v changelogu.
Cursor (Wikipedie) od společnosti Anysphere byl vydán ve verzi 2.0. Jedná se o multiplatformní proprietární editor kódů s podporou AI (vibe coding).
Google Chrome 142 byl prohlášen za stabilní. Nejnovější stabilní verze 142.0.7444.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 20 bezpečnostních chyb. Za nejvážnější z nich bylo vyplaceno 50 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
Pro moddery Minecraftu: Java edice Minecraftu bude bez obfuskace.
Národní identitní autorita, tedy NIA ID, MeG a eOP jsou nedostupné. Na nápravě se pracuje [𝕏].
Americký výrobce čipů Nvidia se stal první firmou na světě, jejíž tržní hodnota dosáhla pěti bilionů USD (104,5 bilionu Kč). Nvidia stojí v čele světového trhu s čipy pro umělou inteligenci (AI) a výrazně těží z prudkého růstu zájmu o tuto technologii. Nvidia již byla první firmou, která překonala hranici čtyř bilionů USD, a to letos v červenci.
Po Canonicalu a SUSE oznámil také Red Hat, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie).
/boot). Nedávno jsem si do stanice koupil NVMe tabletku a moje idea je přemigrovat sistém. Konfigurace cílové migrace: Plně zašifrovaný UEFI boot z NVMe s tím, že boot bude UEFI ->následně Grub2 který bootne btrfs raid 1 mezi oddíly na NVMe tabletce a SSD disku. Přemýšlím o cestách k cíli.Řešení dotazu:
 23.10.2020 00:33
Josef Kufner             | skóre: 70
        23.10.2020 00:33
Josef Kufner             | skóre: 70
            
            
        Taky kernel + initramdisk může být plně šifrovaný (protože GRUB podporuje LUKS). Jediný povinně nešifrovaný oddíl je FAT32 UEFI oddíl, na kterém pak stačí mít pouze moduly GRUBu a jinak nic.
 
            Legacy boot má spoustu nevýhod a (negativních) důsledků, které sahají daleko za pouhý způsob hledání bootovacího média. Takže něco takového bych ani náhodou, ba ani omylem nedělal.
 
            Řekl bych, že web se o tom už rozpovídal víc než dost, takže nemusím já.
Všeho všudy zmíním jako kuriozitu, že dokonce i Snowdenova oblíbená instituce se o tom rozpovídala. Tak kdoví, třeba má v tom UEFI tajný univerzální backdoor. (Který by ovšem bylo snazší dostat do nějakého starého BIOSu, takže to asi nebude ono.)
 26.10.2020 02:10
k3dAR             | skóre: 63
        26.10.2020 02:10
k3dAR             | skóre: 63
            
            
         
             26.10.2020 10:32
k3dAR             | skóre: 63
        26.10.2020 10:32
k3dAR             | skóre: 63
            
            
         a jak sem psal, nejde jen o data, ale o treba o odchyceni tvejch prihlasovacich udaju do prohlizece kde bys klidne pri vypnuti mazal cache...
 a jak sem psal, nejde jen o data, ale o treba o odchyceni tvejch prihlasovacich udaju do prohlizece kde bys klidne pri vypnuti mazal cache... 
             28.10.2020 01:35
k3dAR             | skóre: 63
        28.10.2020 01:35
k3dAR             | skóre: 63
            
            
         
             26.10.2020 10:32
Josef Kufner             | skóre: 70
        26.10.2020 10:32
Josef Kufner             | skóre: 70
            
            
         28.10.2020 01:37
k3dAR             | skóre: 63
        28.10.2020 01:37
k3dAR             | skóre: 63
            
            
         
             28.10.2020 13:42
k3dAR             | skóre: 63
        28.10.2020 13:42
k3dAR             | skóre: 63
            
            
         
             28.10.2020 14:41
Petr Fiedler             | skóre: 35
             | blog: Poradna
        28.10.2020 14:41
Petr Fiedler             | skóre: 35
             | blog: Poradna
            
        Masakr!
encfs za něco svého. Já šifruji hlavně kvůli tomu, aby vyhozený/reklamovaný/odložený/kdovíjaký disk neobsahoval citlivá data – beru to tak, že kdyby měl někdo přístup k mému počítači, tak si s ním může dělat cokoliv – HW keyloggeru, který se dá celkem snadno sehnat, Secure Bootem nezabráním.
encfs nepoužívám a nikdy jsem ho ještě nepoužil. Z FUSE mám pořád takový pocit že to kolečko jádro-userspace-jádro-userspace-… je moc dlouhé. Proti FUSE jako takovému nic nemám, ale pro každodenní používání mi nepřipadá vhodný.
             26.10.2020 00:55
k3dAR             | skóre: 63
        26.10.2020 00:55
k3dAR             | skóre: 63
            
            
         
             28.10.2020 01:48
k3dAR             | skóre: 63
        28.10.2020 01:48
k3dAR             | skóre: 63
            
            
         
             25.10.2020 22:24
Jendа             | skóre: 78
             | blog: Jenda
             | JO70FB
        25.10.2020 22:24
Jendа             | skóre: 78
             | blog: Jenda
             | JO70FB
         26.10.2020 00:52
k3dAR             | skóre: 63
        26.10.2020 00:52
k3dAR             | skóre: 63
            
            
         
            grub-mkimage(1)). Funguje to podobně jako initrd vestavěný do jádra – předáte tomu skriptu obraz disku (memdisk) nebo konfigurační soubor a vygeneruje bootovatelný obraz GRUBu. Pro Leagcy BIOS tam je velikostní limit. Bylo to něco kolem 32 kiB.
             24.10.2020 11:15
Josef Kufner             | skóre: 70
        24.10.2020 11:15
Josef Kufner             | skóre: 70
            
            
         24.10.2020 23:00
k3dAR             | skóre: 63
        24.10.2020 23:00
k3dAR             | skóre: 63
            
            
         25.10.2020 20:46
Jendа             | skóre: 78
             | blog: Jenda
             | JO70FB
        25.10.2020 20:46
Jendа             | skóre: 78
             | blog: Jenda
             | JO70FB
        Bohužel ne. Tady má předřečník tentokrát pravdu, pokud jde o výkon.
Vůbec nejde o rychlost dešifrování kernelu. To je celkem „okamžité“, protože je to celkem běžná symetrická šifra, která se klidně přečte i bez HW akcelerace. (A ano, GRUB (zatím) nepoužívá AES-NI.)
Jde o PBKDF (Password-Based Key Derivation Function). Ta je naschvál pomalá. Většinou se totiž počítají cca statisíce (někdy miliony) hashovacích iterací po nějakou předem stanovenou dobu (implicitně 2 sekundy, pokud se nepletu), než se dojde od člověkem čitelného hesla k LUKS klíči od slotu (který potom následně odemyká master klíč).
Cílem je, aby slabá hesla neznamenala nutně slabé klíče ve slotech. Nevýhodou je, že samotný výpočet PBKDF pak může být klidně časově náročnější než čtení mnoha set MB kernelu + initramdisku.
No a problém je, že když s AES-NI (nebo jinou akcelerací) ty statisíce iterací PBKDF proběhnou (dejme tomu) za dvě sekundy (nebo co si nastavíš v cryptsetup luksAddKey / cryptsetup luksFormat), tak bez HW akcelerace (tedy v GRUBu) bude tentýž výpočet PBKDF a otevření slotu trvat ultra-hyper-dlouho.
Moje zkušenost na skoro dnešním HW (8. generace notebookových procesorů Intel) je, že 2-sekundová PBKDF bude v GRUBu trvat kolem 15 sekund. To je dlouho, ve srovnání s tím, co se očekává od bootu z SSD.
Na starším hardware (4. generace notebookových procesorů Intel) jsem musel ten čas pro PBKDF snížit (u všech používaných slotů; jinak to nemá ten očekávaný efekt) na 500 milisekund, což byla kdysi dávno původní implicitní hodnota. Jinak se totiž v GRUBu stalo, že GRUB dosáhl nějakého svého interního timeoutu (který se nastaví nevímjak; na to jsem nepřišel) a tvrdil, že nemůže odemknout žádný slot, i když měl platné heslo.
Takže tady souhlasím s výhradami ohledně výkonu: Dokud GRUB nebude umět AES-NI (neřkuli vícevláknovost, která je hlavní feature u LUKS2 a PBKDF2), bude tohle kámen úrazu. Na desktopovém hardwaru není co řešit. Nicméně na notebooku, hlavně když bootuje v úsporném režimu na baterii, to může být problém.
 26.10.2020 00:45
k3dAR             | skóre: 63
        26.10.2020 00:45
k3dAR             | skóre: 63
            
            
        nevim co myslis to migraci z klasickeho boot na systemd, pokud init tak to asi s diskem nesouvisi, pokud neco kolem zavadece, tak sicherboot pouziva systemd-boot, kdy sicherboot je v podstate "jen" sada skriptu co ti pripravej vlastni klice, pripravej polozku boot menu pri instalaci/aktualizaci jadra/initramfs s vygenerovanou a podepsanou tvejma klicema efi binarkou obsahujici kernel+initramfs...myslím tím tohle. System je Arch a initramfs stavím podle hooků v této tabulce ve sloupečku "busybox init". Jak jsem psal je to vlastně mnohaletá konfigurace přepisovaná s jednoho systému na druhý. Nicméně pokud chci z initramfs současně otevřít více než jeden device potřebuji přejít z hooku
encrypt na sd-encrypt (to je potřeba abych se dvou device odemkl dva zašifrované oddíly a z nich udělal btrfs RAID 1 a tím pádem je třeba změnit celé generování initramfs a samozřejmě potřebuji to udělat "správně" abych si nenaběhl do situace, kdy mi systém nenajede a mám v něm jen zašifrované disky. (Ano, hlavičky i kliče mám jinde bezpečně uloženy, ale byla by to otrava.) 
Navíc sicherboot pracuje s jinak nazvaným initramfs než pracuje Arch, takže pro jeho použití budou třeba ještě další změny. Ta situace, kterou popisuje Andrej, tedy mít v /efi podepsaný Grub, který odemkne disk, hodí Grub menu, po grub menu natáhne jádro a initramfs ze zašifrovaného /boot, a ze zapečeného kliče v initramfs si jádro odemkne disk ještě jednou a jede dál, mi připadá jako přímočará a jediná nevýhoda je pomalejší odemykání, díky tomu že grub nepoužije HW akceleraci.
             28.10.2020 02:01
k3dAR             | skóre: 63
        28.10.2020 02:01
k3dAR             | skóre: 63
            
            
         26.10.2020 00:51
k3dAR             | skóre: 63
        26.10.2020 00:51
k3dAR             | skóre: 63
            
            
        To je sice všechno pravda, ale pak zase nemůžu mít ultra-tajný kernel + initramdisk, protože je "jenom" podepsaný a každý se na něj může podívat. Všechno má svá pro a proti.
Že současná podpora LUKS v GRUBu potřebuje reimplementaci, to je celkem jasné. PBKDF2 se tam prakticky nedá vypočítat, takže i když GRUB teoreticky LUKS2 podporuje, tohle omezení zatím nepřekonal.
Všechno dohromady (Sicherboot + rychlé otevirání LUKS + tajný kernel) by se asi dalo zařídit pomocí Sicherboot + kexec(), ale konfigurace by byla značný voser, pokud na to není nějaký hotový toolchain.
        Tiskni
            
                Sdílej:
                 
                 
                 
                 
                 
                