Tento týden (24. a 27. června) vyprší platnost Microsoft certifikátu v UEFI vydaných v roce 2011. Nové certifikáty byly vydány v roce 2023. Kdo na počítačích, i virtuálních, používá zabezpečené spouštění (Secure Boot), měl by si ověřit, že má certifikáty aktualizovány, viz např. články na Red Hat nebo Fedora. Pro stávající systémy se nic nemění. Nadále se budou normálně spouštět. Zavaděče podepsané pouze klíčem z 2023 se ale na počítačích s pouze certifikátem 2011 nespustí. Ve Fedoře je zavaděč shim ve verzi 16.1-6 podepsán klíči 2011 i 2023.
Uživatelé mobilních telefonů s Linuxem si nyní mohou nainstalovat aplikaci Mobilní Datovka. Díky tomu je přístup k datovým schránkám dostupný i na zařízeních s mobilními linuxovými distribucemi, jako jsou například Mobian, NixOS Mobile, pmOS atd. Aplikace je dostupná na Flathubu.
Software Freedom Conservancy v novém dokumentu shrnuje doporučení, jak přistupovat ke generativní AI založené na LLM při přispívání do svobodného a open-source softwaru. Mimo jiné vyzývá k obezřetnosti, transparentnosti a revizi generovaného kódu člověkem.
Byla vydána nová verze 5.6.0 programu na úpravu digitálních fotografií darktable (Wikipedie).
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma. V Týdnu v GNOME je zmíněn flatpak balíček pro GIMP 0.54.1 z roku 1996. Jedná se o poslední verzi GIMPu postavenou nad toolkitem Motif.
Home Assistant Operating System, tj. linuxová distribuce optimalizována pro hostování Home Assistanta a jeho aplikací, byl vydán v nové major verzi 18.0.
Po šestiletém úsilí byla z jádra Linux odstraněna funkce strncpy(). Všechna předchozí volání této funkce byla převedena na bezpečnější alternativy.
Byla vydána nová verze 261 správce systému a služeb systemd (Wikipedie, GitHub). Z novinek lze vypíchnout nový subsystém IMDS (Cloud "Instance Metadata Service"), nový příkaz storagectl nebo novou komponentu systemd-sysinstall.
Vývojové prostředí Qt Creator bylo vydáno ve verzi 20 (seznam změn). Novinky zahrnují hlavně rozšíření pro integraci LLM agentů nebo minimalistický editační režim uživatelského rozhraní („zen mode“).
Už jste se prolétli na webu Google Earth? Přibyl tam Simulátor letu (Nástroje / Simulátor letu). Funguje i bez účtu Google [𝕏].
Jaká je principiálně výhoda SSL oproti GNUPG? V článku se píše, že tím hlavním rozdílem, je to, že u SSL stačí znát CA aby si oba důvěřovali, ale u GNUPG přesi stačí si osobně vynměnit klíče a je to ještě bezpečnější. A když si mohu zajistit certifikát od CA, tak proč bych si nemohl zajistit GPG klíč od protistrany? Navíc GPG klíč mohu dále podepisovat a distribuovat, takže to funguje tak nějak přirozeně samo. To mě totiž vytáčí, že úřady začínají požadovat certifikáty, za které by bylo nutné platit CA a odmítají si vyměnit klíče osobně. Jaký je problém aby patřičný úřad byl defakto takovou CA?
že občanské průkazy jsou nesmysl, že by stačilo, kdybyste se každému úřadu prokázal jinak, že se jedná zrovna o VásDovede-li se tato představa důsledně do analogie s PGP, musel byste s sebou přivést někoho (A), kdo vás zná. Ten (A) by s sebou přivedl někoho (B), kdo zná jeho (A). (B) by s sebou přivedl někoho... až někonec by byl někdo (X), koho zná úředník
Podle 6 stupňu odloučení by vám měli stačit 4 lidi
25.2.2006 12:18
Petr Tomášek | skóre: 39
| blog: Vejšplechty
)
Druhá výhoda CA je ta, že ručí za certifikát přímo. U GPG víte, že Franta podepsal klíč Pepovi, Frantovi ho podepsala Jitka, Jitce Blanka, a s Blankou jste si klíš vyměnil. Budete všem těm lidem mezi opravdu věřit? Úřad jim samozřejmě věřit nemůže, a nelze se na tento řetězec spolehnout ani v žádném případě, který má mít nějakou právní váhu - všechny ty články řetězu by se totiž stali spoluručiteli, a to předem, aniž by věděli, za co vlastně ručí.
Úřad si s vámi nemůže vyměňovat klíče a být "takovou" CA, protože úřad si nemůže dělat, co se mu zlíbí - vynakládat "jen tak" peníze na vytvoření důvěryhodné CA, zaškolovat lidi apod.
Od toho tu tá diskusia je Nikde netvrdím, že som miestny expert na SSL. Je pravda, že článok je miestami nepresný. Ale cieľom je vysvetliť princípy. A neunudiť pritom čitateľa na smrť.
- To nie je specifickou vlastnostou SSL, ze prijemca a odosielatel sa nemusia poznat. To je vlastnost PKI.
To tiež nie je celkom presné. V článku poukazujem na to, že fyzické overenie toho, že certifikát C patrí osobe O robí certifikačná autorita a nie ten, kto skúma konkrétny elektronický podpis nejakého dokumentu.
- Co ste napisali: "Ak dostanem správu od používateľa XY a tá správa je podpísaná jeho certifikátom," je upl na haluz .. sprava (presnejsie jej hash) sa podpisuje sukromnym klucom a v certifikate je ulozeny len k nemu zodpovedajuci verejny kluc.
Správne.
- CA nepotrebuju na svoju cinnost "povolenie na cinnost", ale akreditaciu od Narodneho bezpecnostneho uradu.
Slovník vraví akreditácia == "úradné oprávnenie vykonávať istú činnosť"
- Garantom el. podpisu (podla ceskeho zanoka digitalneho) v ceskej republike nie je NBU, ale ministerstvo in formatiky.
Dobre vedieť. To som nevedel a o právnom pozadí v ČR som sa vyjadroval
v článku dosť opatrne
- NBU nevydava "bezpecnostne predpisy pre CA". Hlavnym predpisom CAcky je jej bezpecnostna politika. TU si v ydava sama. NBU moze na CA posobit len bez vyhlasky, alebo (ne)udelenim akreditacie.
Tak dobre. Ja neprevádzkujem verejnú CA a ten, kto ju chce prevádzkovať musí vedieť viac, ako to čo je v tomto článku. NBÚ SR publikuje na svojich stránkach "metodika auditu SW aplikácií pre ZEP","vzor protokolu o kompilácii", "Schválené formáty" a niekoľko vyhlášok a predpisov popisujúcich najrôznejšie aspekty od technického zabezpečenia budov CA, cez off-site backup-y, disaster recovery a podobne. Ak sa cítiš dostatočne fundovaný, tak o tom napíš článok. Čitatelia budú vďační.
- CA EVPU nesidli v Dubnici nad Vahom, ale v Novej Dubnici.
Pravda je. Vzhľadom na to, že sme na českom serveri a väčšina čitateľov by mala problém nájsť to na mape - dúfam, že mi odpustia.
- Nie je pravda, ze konfiguracny subor "by mal byť spravidla umiestnený v /etc/ssl/openssl.cnf". Napriklad j a ho mam na linuxe v /usr/lib/ssl/openssl.cnf, na solarise bol defaultne ulozeny /usr/local/ssl/openssl.cnf.
Ok. Podla zdrojákov, je default /usr/local/ssl -
ale do hry vstupuje LSB, ktoré hovorí, že system-wide konfigurácia
má byť pod /etc.
Xerces: S PGP skusenosti nemam, aj ked s el. podpisom robim uz 2 roky(robim = je to hlavna napln mojej prace). Jedna k na komunikaciu medzi serverom a klientom mozes pouzit len SSL. To je hlavnou naplnou tohto protokolu.
To bude vysvetľovať, prečo mám pocit, že Ťa ten článok zdvihol zo stoličky.
Pass phrase nie je "heslo, ktoré budeme používať pri vytváraní elektronického podpisu". Je to o tom, ze privatny kluc je ulozeny v zasifrovanej pomocou symetrickej sifry. Kluc, ktorym je zasifrovany sa ziskal z tohto hesla.
Správne. Uff. Je piatok vecer a ja mam dost. Bol by si ochotný urobiť reviziu druheho dielu članku?
Nie, my Novodubničania ti neodpustíme :) A Novú Dubnicu vôbec nie je ťažké na mape nájsť. Nájdeš ju aj na Google Earth.
Ak sa cítiš dostatočne fundovaný, tak o tom napíš článok.
Ty ho píšeš a vzhladom na množstvo nepresností, na ktoré ťa lovec upozornil, by si na svojej fundovanosti mal poriadne zapracovať.
Inak, dobrá téma.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czRSpublickey (logicky z nazvu - verejny klic) musi ho mit i prijemce,ze?
RSprivatekey (logicky z nazvu je to prave to oko v hlave - privatni klic)
RScertificate.pem (co je ale toto? To je snad privatni klic vcetne verejneho klice? Tomu prave nejak nerozumim).
A soubor p12 je nejaky balik privatniho a verejneho klice, co akceptuji mailovy klienti?
Snad pochopite o co mi jde a pripadne mi poradite. Budu Vam moc vdecny. Karlik
Tiskni
Sdílej:
