Microsoft vydal novou velkou aktualizaci 2404.23 v září 2019 pod licencí SIL Open Font License (OFL) zveřejněné rodiny písma Cascadia Code pro zobrazování textu v emulátorech terminálu a vývojových prostředích.
OpenTofu, tj. svobodný a otevřený fork Terraformu vzniknuvší jako reakce na přelicencování Terraformu z MPL na BSL (Business Source License) společností HashiCorp, bylo vydáno ve verzi 1.7.0. Přehled novinek v aktualizované dokumentaci. Vypíchnout lze State encryption.
Spouštět webový prohlížeč jenom kvůli nákupu kávy? Nestačí ssh? Stačí: ssh terminal.shop (𝕏).
Yocto Project byl vydán ve verzi 5.0. Její kódové jméno je Scarthgap. Yocto Project usnadňuje vývoj vestavěných (embedded) linuxových systémů na míru konkrétním zařízením. Cílem projektu je nabídnou vývojářům vše potřebné. Jedná se o projekt Linux Foundation.
Operační systém 9front, fork operačního systému Plan 9, byl vydán v nové verzi "do not install" (pdf). Více o 9front v FQA.
Svobodná webová platforma pro sdílení a přehrávání videí PeerTube (Wikipedie) byla vydána v nové verzi 6.1. Přehled novinek i s náhledy v oficiálním oznámení a na GitHubu. Řešeny jsou také 2 bezpečnostní chyby.
Lennart Poettering na Mastodonu představil utilitu run0. Jedná se o alternativu k příkazu sudo založenou na systemd. Bude součástí systemd verze 256.
Hudební přehrávač Amarok byl vydán v nové major verzi 3.0 postavené na Qt5/KDE Frameworks 5. Předchozí verze 2.9.0 vyšla před 6 lety a byla postavená na Qt4. Portace Amaroku na Qt6/KDE Frameworks 6 by měla začít v následujících měsících.
Byla vydána nová verze 2.45.0 distribuovaného systému správy verzí Git. Přispělo 96 vývojářů, z toho 38 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání. Vypíchnout lze počáteční podporu repozitářů, ve kterých lze používat SHA-1 i SHA-256.
Ty role klíčů jsou čtyři:
Defaultně gpg vyrobí master [SC] a subkey [E], ale lze to kombinovat i jinak, např. mít jeden master klíč pro všechny čtyři (to se moc nedoporučuje) nebo naopak čtyři různé (master [C], subkeys [S], [E] a [A]). Je možné i mít víc klíčů se stejnou rolí, např.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
mike@lion:~> gpg --list-keys --list-options show-unusable-subkeys 329DD07E
pub rsa4096 2011-11-07 [SC]
DE0E66E32F1FDD0902666B96E63EDCA9329DD07E
uid [ full ] Konstantin Ryabitsev <konstantin@linuxfoundation.org>
uid [ full ] Konstantin Ryabitsev <mricon@kernel.org>
uid [ full ] Konstantin Ryabitsev (Fedora) <icon@fedoraproject.org>
uid [ full ] [jpeg image of size 2774]
uid [ unknown] Konstantin Ryabitsev <icon@mricon.com>
uid [ unknown] Konstantin Ryabitsev <hbic@paranoidbeavers.ca>
sub rsa4096 2011-11-07 [E] [revoked: 2012-01-27]
sub rsa3072 2012-01-26 [S] [revoked: 2014-06-03]
sub rsa2048 2012-01-26 [E] [revoked: 2014-06-03]
sub rsa2048 2014-06-03 [A] [revoked: 2018-05-02]
sub rsa2048 2014-06-03 [S] [expired: 2015-11-03]
sub rsa4096 2015-11-02 [S] [expired: 2018-05-09]
sub rsa4096 2015-11-02 [A]
sub ed25519 2018-02-09 [S]
sub cv25519 2018-05-02 [E]
sub rsa2048 2018-05-02 [A]
sub rsa2048 2012-01-26 [A] [expired: 2015-11-03]
sub rsa2048 2014-06-03 [E] [expired: 2015-11-03]
sub rsa4096 2015-11-02 [E] [expired: 2018-05-09]
Jediné, čím si nejsem jistý, jestli vůbec lze, je mít [C] u subkey. Tahle role je nejdůležitější, je potřeba ke kritickým operacím jako podepsání klíče nebo identity, přidání nebo revokace identity, změna expirace atd. Proto se doporučuje master key (tedy tajný klíč od něj) vůbec nemít na běžně používaném počítači, ale typicky na nějakém dobře chráněném vyměnitelném médiu se šifrovaným filesystémem.
Vidíme, že se použila první identita. Ale nevím, jestli se použil master key nebo subkey. Po pravdě, nevím, co znamená ten šílený výraz 5ABA0105F9EEDE9BD0021DC08F2D5825D5689DE1.
Je to hash (SHA-1) toho klíče (někde v dokumentaci by se dalo najít, z čeho přesně se počítá). Podle toho, jak moc unikátní identifikátor chcete, se používá buď celý hash, posledních šestnáct číslic nebo posledních osm číslic, tj.
D2CB120AB45957B721CD9596F4554567B91DE934
F4554567B91DE934
B91DE934
identifikují stejný klíč.
Fingerprinty všech klíčů (včetně subkeys) si můžete zobrazit např. takhle:
mike@lion:~> gpg --list-keys --with-subkey-fingerprint B91DE934
pub rsa4096 2020-05-14 [C]
D2CB120AB45957B721CD9596F4554567B91DE934
uid [ultimate] Michal Kubecek <mkubecek@suse.cz>
uid [ultimate] Michal Kubecek <mkubecek@suse.com>
uid [ultimate] Michal Kubecek <mike@mk-sys.cz>
uid [ultimate] Michal Kubecek <mkubecek@suse.de>
sub rsa2048 2020-05-14 [S]
58DDE3DDB89E566A76EA628EE77F2C1BF2D17695
sub rsa2048 2020-05-14 [E]
13B2B514E8EDD8702D4A9DEB094C2AAB78F838CB
sub rsa2048 2020-05-14 [A]
44392E315CF737665DBF98AA0FB671160C864DA3
Ve vašem případě jde určitě o subkey, protože master by byl "153130ED26CA404C8B29795B4703A5B671B96E4D".
-s" (--sign) používá volba "-b" (--detach-sign), která nechá podepisovaný soubor jak je a vytvoří samostatný soubor s podpisem. Většinou se navíc přidává volba "-a" ("--armor"), aby byl soubor s podpisem textový.
28.5.2020 07:34
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Což má za následek, že když někdo podepíše cizí veřejný klíč, může někoho uvést v omyl, že tento klíč patří někomu jinému, než kdo ho vydal. (https://nullprogram.com/blog/2019/07/10/, článek datovaný July 10, 2019). V diskusi ke článku uživatel zaarn nebral servítky a na adresu GPG doslova napsal (ač nedoplněno emotikony, každý v tom jistě cítí sarkasmus):Já jsem si poslední dobou několikrát všiml, že je v módě kopat do GPG / PGP, jako že je to moc složité a nahovno. Přijde mi, že je to poslední dobou nějaký hipster hnutí, akorát když se v těch diskuzích zeptáš čím to teda nahradit, tak vytáhnou nějakou blbost, která často ani není asymetrická a začnou ti jí cpát s naprosto očividným nepochopením k čemu se asymetrická kryptografie běžně používá. Zase to samé z toho na nullprogramu:Man, where would we be without the people that defend GPG? Possibly in a world with easy-to-use mail cryptography solutions but who wants that?
Why only a signing key? Nobody should be using OpenPGP for encryption anymore. Use better tools instead and retire the 20th century cryptography. If you don’t have an encryption subkey, nobody can send you OpenPGP-encrypted messages.Jasně, určitě, ale co? Tam dává odkaz, který se odkazuje na What’s the matter with PGP?, což taky nedává žádné odpovědi. Asi jediné, co jsem viděl že by mohlo nahradit část funkcionality gpg je signify. BTW: Spoustu těch odkazů máš blbě, protože ti tam vlezly nějaké uvozovky.
Jestli to dobře chápu, tak kromě jsou tam v podstatě tři výhrady:
1. To je opravdu problém, pokud chceme podepisování a šifrování komunikace i mimo komunitu technických nadšenců. Prostý uživatel nechce věcem rozumět a už vůbec o nich nechce přemýšlet. Koncept web of trust ale tohle po uživateli vyžaduje. Je to vidět i z těch rantů - těm lidem je cizí představa, že by měli rozlišovat mezi "mám něčí veřejný klíč" a "mám jeho dodstatečně ověřený veřejný klíč" a chovat se podle toho. Proto se v komerčních produktech prosadila spíš řešení založená na konceptu PKI (S/MIME pro e-mail), a to ještě implementovaná tak, aby si uživatel nemusel (a někdy ani nemohl) dělat management certifikátů sám. Tam není potřeba přemýšlet, prostě mám certifikáty podepsané autoritami a kterým autoritám mám věřit, to mi řekne Microsoft, Google nebo Mozilla Foundation. Ono už to slovo "autorita" vzbuzuje důvěru, jen nebezpeční anarchisti přece nevěří autoritám. :-)
2. Tohle je asi jediný problém, se kterým se dá souhlasit, ale autor sám přiznává, že u e-mailu to už z principu jde řešit jen částečně.
3. Tohle je zcela obecný problém, nijak specifický pro openpgp. Jedno možné "řešení" je udělat to jako wireguard, tj. zafixovat konkrétní "bezpečnou" sadu algoritmů a parametrů a když (nebo spíš "až") se ukáže, že už nestačí, tak se přejde na novou, zpětně nekompatibilní verzi protokolu. Kde je problém tohoto řešení, to asi nemusím dlouze vysvětlovat. Stačí se podívat po diskusích, jak se pokaždé, když v openssl nebo openssh odstraní podpora nějakého zastaralého algoritmu nebo kombinace, začnou admini chytat za hlavu: "Ale to mi nebude fungovat s (nějaká roky neaktualizovatelná krabička)."
Bod 1 asi nejlépe ilustruje tenhle komentář z tamní diskuse:
Believe me, I know about X.509, and I have spent far too long staring at the output of `openssl x509 -text -noout`. It's still better than PGP, because the web PKI model makes sense to people who aren't cryptogeeks (“I trust Verisign, and Verisign verifies me, and Firefox trusts Verisign to verify me”), and the tools are usable by people who aren't cryptogeeks.
You never even have to understand X.509 or PKI to get a HTTPS web server up and running which provides reasonable security guarantees. Every CA will tell you exactly how to generate a reasonable cert and how to install it in your web server of choice.
Pro lidi, kteří uvažují takhle (a obávám se, že jich je většina), openpgp opravdu není.
Pro lidi, kteří uvažují takhle (a obávám se, že jich je většina), openpgp opravdu není.No jo, ale co tedy navrhuješ? Aby lidi přestali být blbci? Já se přiznám bez mučení, že PGP a GPG taky moc nerozumim a děsí mě představa, že to budu muset začít řešit (což asi budu muset), zabřednout do toho celého bordelu popsaného v blogu, v diskusi a jinde a strávit tim kdovíkolik hodin času jenom proto, abych získal jakous takous podprůměrnou schopnost s tou věcí pracovat... Jo a pak ve výsledku stejně narazim na nějakej absurdně hloupej problém, jakože např.
pgp.mit.edu je směšně poddimenzovaný server, který 98% požadavků dropne a submitnout klíč se tam prakticky nedá...
No jo, ale co tedy navrhuješ? Aby lidi přestali být blbci?
Ještě to tak, přijít o konkurenční výhodu. :-)
Ale teď vážně: samozřejmě si nemyslím, že openpgp je model rozumně použitelný pro široké masy nepoučených (a nepoučitelných) uživatelů. Jen zásadně nesouhlasím s tvrzením, že to znamená, že je celý ten model špatně navržený. V rámci komunity dostatečně fundovaných uživatelů (a zase až tak hluboké znalosti k tomu potřeba nejsou) funguje naopak mnohem lépe než ten PKI model preferovaný širokou veřejností. Když zjistím, že se závodní speciál nehodí k ježdění po polních cestách nebo popojíždění v kolonách na magistrále, tak z toho taky nevyvodím, že je k ničemu.
Pokud k tomu ale někdo přistupuje tak, že ho žádná filosofie a vnitřní logika nezajímá, je dost pravděpodobné, že mu spousta věcí dávat smysl nebude a bude se s tím prát. A pokud k tomu bude přistupovat s tím, že je to navržené od základu špatně, je to téměř jisté.No jo, nicméně to, že ty (nebo já, to je jedno) jsi tu vnitřní filosofii vstřebal, neznamená, že je skutečně dobrá a dobře pochopitelná pro ostatní lidi. Já sice aktuálně neznám lepší nástroj než git na VCS, ale nejsem úplně přesvědčen, že filosofie gitu je a) skutečně dobrá a b) dobře uchopitelná pro "kohokoli", i když "kohokoli" zúžím na lidi jako jsou programátoři, admini, linux nerdi apod. Třeba v darcsu nebo Pijulu si myslí, že filosofie gitu je špatná:
What’s wrong with existing, widely-used, mature solutions? Some things are really wrong, like using three-way merge for version control in general: there are examples (even real-world ones) where Git, Mercurial and SVN just do the wrong thing. See this article for more details. Less objectively, our experience with patch-based tools make us believe that this is possibly the simplest way to control versions.Případně, méně vážně, viz xkcd ... Umim si představit, že s gpg to může být podobné, případně horší než s gitem (gpg asi zná míň lidí).
[...] See this article for more details.Ten příklad je prostě jen nejednoznačný a různé nástroje ho vyřeší různě. Ani jedna varianta není špatně.
28.5.2020 21:18
square() tam vrací vždy nulu (protože VCS aplikoval změnu c1 na špatnou funkci).
Ta změna C říká, že ve funkci square bude na začátku y = 0.To ale programátor píšící změnu C zřejmě nechtěl... Resp. chtěl by, aby ta změna se s přesunem a přejmenováním te funkce také přesunula.
Když by kód té funkce vypadal trochu jinak, tak by byla špatně darcs verze.Ano, ten příklad tam taky je popsanej, ale je oproti tomu příkladu, kdy git to má špatně, je příšerně vykonstruovaný a nereálně vypadající, musí se tam v podstatě "správným" způsobem náhodou potkat dva různé bugfixy, aby to git měl ve výsledku správně.
Merge prostě nemůže vědět, jestli se ten kus kódu opravdu přesunul, nebo jen na chvíli zmizel (např. revertnutý commit).Ano, merge to vědět nemůže, ale VCS založené na patch theory tohle právě vědí. Tohle je přesně ten problém, o kterým mluvim a proč jsem git zmínil: Lidi, kteří do
$technologie investovali čas, rozumí jí a jsou na ni zvyklí, mají tendenci automaticky předpokládat, že ta filosofie té věci je správná a že ten, kdo ji kritizuje, to nejspíš dělát protože jí nedostatečně rozumí.
Realita… je taková, že žádný algoritmus pro merge vám nezaručí, že za kterýchkoli okolností vyprodukuje správný výsledek nebo aspoň zahlásí konflikt, který je potřeba vyřešit ručně. (Tedy kromě triviálního, který zahlásí neřešitelný konflikt pokaždé.) Zkuste si představit něco tak jednoduchého (a naprosto realistického) jako třeba větev A o jednom patchi, který přidá funkci další parametr (a upraví všechna volání), a větev B o jednom patchi, který přidá nové volání té funkce do souboru, kde předtím žádné nebylo. A to ještě budete mít štěstí, že na to přijdete hned při překladu; pokud by se té funkci jen změnilo chování nebo třeba interpretace parametru nebo návratové hodnoty, může z toho vzniknout bug, který se projeví jen za specifických okolností.
To ale samozřejmě nebrání autorům VCS provozovat podobné soutěže "kdo vejš", konstruovat příklady, které ten jejich vyřeší dobře a konkurenční ne, a dohadovat se, čí příklad je více nebo méně umělý.
Proto jsem přidal i ten druhý odstavec, kde jsem napsal, co si myslím o tom "lépe".
Ze své zkušenosti ani z ohlasů ve svém okolí nemám pocit, že by úspěšnost a spolehlivost merge algoritmu gitu byla tím, co by vývojáře nějak zásadně trápilo. S problémy toho typu, že backport nefunguje správně kvůli tomu, že se mezi místem, odkud se backportuje, a místem, kam se backportuje, něco změnilo, se setkávám častěji. (To je samozřejmě cherry pick a ne merge, ale problém je stejný.)
Pokud chces ukazat, ze filosofie darcsu je lepsiNechci.
pak by jsi to mel ukazat na nejakem relevantnim prikladu. Coz to co jsi odkazal rozhodne neni.Ten příklad IMO celkem jasně ukazuje určitou převahu darcsu a souhlasim s autorem tý stránky, že ten protipříklad, kdy v gitu to dopadne lépe, na tom nic nemění, vzhledem k tomu, jak uměle je zkonstruovaný a jak příšerně ten kód v něm vypadá (oproti tomu ten pro-darcs příklad je celkem normální kód). Stejnětak si nemyslim, že by na tom cokoli měnil Kubečkovo příklad, ve kterém dopadnou špatně oba. Jestli celkově - nejen co se týče mergingu - je filosofie darcsu/Pijulu lepší, to je mnohem širší otázka a odpověď neznám. To bych musel darcs nebo Pijul aktivně používat na netriviálním projektu, ideálně souběžně s gitem. Jak už jsem napsal v pdůvodním příspěvku, neznám aktuálně vhodnější software na VCS než git. Co ale nechci je povýšit neznalost jiných přístupů k VCS na tvrzení, že filosofie gitu je nejlepší (kde ta neznalost být může způsobená mj. i tím, že ten lepší přístup třeba ještě nikdo nevymyslel/nenaimplementoval).
Jestli celkově - nejen co se týče mergingu - je filosofie darcsu/Pijulu lepší, to je mnohem širší otázka a odpověď neznám. To bych musel darcs nebo Pijul aktivně používat na netriviálním projektu, ideálně souběžně s gitem.Konkrétně např. darcs nemá branche a místo toho zřejmě se tam dělají klony do různých adresářů. Jestli to je dobrý/špatný přístup, to fakt nevim. (Default u člověka zvyklýho na git je říct, že to je špatně, ale nevyzkoušel jsem si to, takže těžko říct.) Je pravda, že v gitu u větších projektů používám workdirs, což bych asi v případě darcsu nemusel řešit a měl bych to tak rovnou. Pijul branche má, ale nevim, jak přesně fungují / jakou mají sémantiku...
int square(int x) {
int y = x;
/* Update y to equal the result. */
/* Question: what is the order of magnitude of this algorithm with respect to x? */
for (int i = 0; i < x; i++) y += x;
return y - x;
}
tak jsou v haji oba.
Migrovat cokoli na jiný VCS je moc komplikovaná věc na to, aby se to dělalo jen proto, že je ten nový nástroj v něčem o chloupek lepší - což tady navíc není ani zdaleka jisté, protože tady máte v ruce jeden vykonstruovaný testcase a tvrzení (z ne zrovna nezaujatého zdroje), že neexistuje realistický testcase, kde by to bylo naopak. A to se pořád bavíme jen o zlomku toho, co git nabízí. Půjde v tom darcsu stejně efektivně pracovat s desítkami nebo stovkami větví a tagů? Co jsem se díval na ten model, tak to vypadá, že větve ani tagy nejsou v tomhle modelu ani zdaleka tak "levné" a praktické jako v gitu.
Nový nástroj musí být výrazně lepší než stávající široce rozšířený, aby to vývojáře přimělo na něj přejít. Často dokonce ani to nestačí a je navíc potřeba určitá míra nespokojenosti s tím stávajícím. Je mi líto, ale tady nevidím ani jedno. On i takový přechod ze subversion na git u některých projektů trval dost dlouho, přestože byly výhody gitu očividné a nevýhody bylo potřeba hledat opravdu pečlivě. A třeba migrací projektů mezi gitem a mercurialem je minimum, protože tam v podstatě jediná opravdu výrazná výhoda je "používají (a znají) to skoro všichni" (ve prospěch gitu).
Může vám to připadat nespravedlivé, ale podle mne je to dobře. Čas vývojářů je totiž omezený zdroj a když se ho moc spotřebuje na neustálé sledování a vyhodnocování nových cool nástrojů a migrování mezi nimi, hrozilo by, že nebudou mít čas na projekt samotný.
Také bych rád upozornil, že jsem nemluvil o potřebě filosofii gitu milovat nebo ji považovat za skvělou, nejlepší nebo dokonce jedinou dobrou. Mluvil jsem jen o potřebě ji chápat a rozumět jí - a o tom, že apriorní přístup "je to celé úplně blbě navržené" vede logicky ke špatným výsledkům. To je hodně podstatný rozdíl.
A konečně: tahle větev diskuse se rozvinula v něco, co je ještě více off-topic než ta větev, se kterou jsem se rozhodl skončit včera, takže se pokusím dále nepokračovat i v ní.
Migrovat cokoli na jiný VCS je moc komplikovaná věc na to, aby se to dělalo jen proto, že je ten nový nástroj v něčem o chloupek lepšíAno, však taky používám víceméně spokojeně git, migrovat se necyhstám a ani jsem k tomu nikoho nenabádal
Může vám to připadat nespravedlivé, ale podle mne je to dobře. Čas vývojářů je totiž omezený zdroj a když se ho moc spotřebuje na neustálé sledování a vyhodnocování nových cool nástrojů a migrování mezi nimi, hrozilo by, že nebudou mít čas na projekt samotnýPřímo v komentáři, na který reaguješ, píšu tohle:
Aby bylo jasno: Já s těma nástrojema jako darcs nebo Pijul nemam zkušenost na netriviálním projektu (zkoušel jsem to jen trochu, nemam na to moc času)Nevim, co k tomu víc říct...
Také bych rád upozornil, že jsem nemluvil o potřebě filosofii gitu milovat nebo ji považovat za skvělou, nejlepší nebo dokonce jedinou dobrou. Mluvil jsem jen o potřebě ji chápat a rozumět jí - a o tom, že apriorní přístup "je to celé úplně blbě navržené" vede logicky ke špatným výsledkům. To je hodně podstatný rozdíl.To je těžký. Na jednu stranu máš pravdu v tom, že jsou lidi, který prostě řeknou "je to celý úplně blbě" a aniž by se zajímali to smetou ze stolu. To souhlasim, že je špatně. Na druhou stranu když nemalé množství lidí včetně lidí inteligentních a pracovitých má s nějakou technologií problém a/nebo ta technologie způsobuje nemalé problémy, tak se nedá tak úplně vyloučit, že na ní opravdu je něco špatně, a to třeba i dost podstatně. Je to příliš heretická / neakceptovatelná / děsivá myšlenka? Asi ano.
Stejně jako u openpgp, ani o gitu si nemyslím, že by to bylo nejlepší řešení pro všechny. Koneckonců je pořád dost projektů, které spokojeně používají třeba subversion. Nebo aspoň ne dost nespokojeně, aby je to motivovalo ke změně. :-)
Mně prostě ze všech těch výkřiků, jak je openpgp (gpg) špatně navržené, čiší logika "když to nevyhovuje mně pro můj use case, tak je to prostě blbost". Ale to je logika, kterou považuju za zvrácenou. Ony ty nástroje, které se snaží být (jakž takž) použitelné na cokoli, často končí tak, že se opravdu dobře nehodí na nic.
Git má taky svou filosofii a model, který když pochopíte a akceptujete, tak je to všechno (no, většina) logické a dává to dobrý smysl.Neni to jen o znalosti te filozofie. Kdyz si vybavim uplne prvni verze gitu, bylo to na ovladani opravdu hodne neprijemne.
Prostý uživatel nechce věcem rozumět a už vůbec o nich nechce přemýšlet.Ono nejde ani tak o to,jestli o tom chce nebo nechce přemýšlet prostý uživatel. Ono jde především o to, jestli vy chcete, aby o tom ten uživatel přemýšlel. Asi byste nechtěl, abyste jeden měsíc poslal hlášení k DPH podepsané PGP a úředník by vám to bez problémů přijal, protože vašemu klíči věří, a za měsíc byste poslal další hlášení podepsané tímtéž klíčem, ale jako odpověď by vám přišla pokuta, že jste hlášení nepodal – protože to přijal jiný úředník, který vašemu klíči nevěří. Nebo byste se hlásil na vysokou školu, ale nevzali by vás, protože referentka na studijním oddělení nevěří PGP klíči ředitele vašeho gymnázia, který podepsal vaše maturitní vysvědčení. Zkrátka to, že se nad ověřováním klíčů nepřemýšlí, ale používá se předvídatelný a reprodukovatelný formální postup, má své dobré důvody, a umožňuje PKI fungovat mimo komunitu – tedy i ve společnosti, která je tak velká, že se její členové ani zprostředkovaně neznají. PGP je použitelné mimo komunitu technických nadšenců, ale není použitelné mimo komunitu (jakoukoli). Výhodou PGP naopak je to, že je tam mnohem víc vidět to, že jde pořád jen o klíče, a mnohem víc se pracuje s těmi klíči – a teprve k nim je nějak navěšená důvěra. Kvůli té fixaci PKI na certifikáty pak máme pořád takový nesmysl, jako jsou DV certifikáty, kdy se certifikační autority zaručují za doménové jméno, za které se ale nijak zaručit nemohou. Přitom důležité je jenom to, že nějaký klíč patří k dané doméně – a to dnes může být bezpečně uložené v DNS.
Ono nejde ani tak o to,jestli o tom chce nebo nechce přemýšlet prostý uživatel. Ono jde především o to, jestli vy chcete, aby o tom ten uživatel přemýšlel. Asi byste nechtěl, abyste jeden měsíc poslal hlášení k DPH podepsané PGP a úředník by vám to bez problémů přijal, protože vašemu klíči věří, a za měsíc byste poslal další hlášení podepsané tímtéž klíčem, ale jako odpověď by vám přišla pokuta, že jste hlášení nepodal – protože to přijal jiný úředník, který vašemu klíči nevěří.
To není moc dobrý příklad, protože přestože státní správa sice používá PKI infrastrukturu, ale používá ji způsobem, který je vlastně implementací web of trust: pro oficiální komunikaci se státní správou je totiž potřeba mít certifikát přímo podepsaný jednou z poměrně malého počtu autorit, kterým stát věří. A to je něco, co by šlo stejně (ne)snadno implementovat i nad openpgp.
To, co jsem zpochybňoval, je způsob, jakým se PKI běžně používá ve webových prohlížečích a pravděpodobně i mainstreamových MUA: vendor mi software (nebo rovnou OS) dodá s docela dlouhým seznamem "důvěryhodných" autorit, do kterého by se klidně vešel i Honest Achmed, kdyby byl jen o chloupek méně upřímný. Ale uživatel vidí zelený zámeček, přečetl si, že zámeček je dobře, tak je happy.
Celý problém je podle mne v tom, že těch situací, kdy požadavky bezpečnosti a pohodlí nejsou protichůdné, je poměrně málo. A je chyba předstírat, že to tak není.
To je všechno hezké, ale pořád to není nijak v rozporu s mým tvrzením, že (1) fungování kvalifikovaných certifikátů (nebo jak přesně to právníci nazvali) je hodně odlišné od toho, jak se PKI běžně používá v prohlížečích a MUA a (2) to, že se openpgp model nehodí pro široké masy, ani zdaleka neznamená, že je špatně navržený; prostě je jen navržený pro jiné účely a jiné prostředí, kde funguje naopak výrazně lépe.
Nemyslím si, že bezpečnost a pohodlí jsou tak často v protikladu – ve spoustě případů je to jen lenost vymyslet to řešení pořádně.
Obávám se, že takdy se prostě neshodneme, protože zrovna ten příklad, který jste sám vybral, to ilustruje dost názorně: srovnejte si třeba, jak náročné je získat kvalifikovaný certifikát ve smyslu zákona a jak náročné je získat ho třeba u Let's encrypt nebo některé jiné "pohodlné" autority. A doufám, že mi nebudete tvrdit, že je důvěryhodnost takových certifikátů na stejné úrovni nebo že snad na tom ty druhé budou lépe.
Samozřejmě se najdou i případy, kdy je jedno řešení bezpečnější i pohodlnější než druhé; příkladem může být třeba autentizace pomocí klíčů místo hesel u ssh. Ale moc časté to rozhodně není.
zrovna ta delegace ověřování identity na certifikační autority v drtivé většině případů bezpečnost zvyšuje
Tato věta je obsahově prázdná, pokud neřeknete, oproti čemu ji má zvyšovat. Oproti tomu, když se identita nebude ověřovat vůbec, rozhodně ano, ale to není moc vysoko nastavená laťka. Oproti web of trust modelu provozovanému dostatečně informovanými a zodpovědnými uživateli… ani náhodou.
Teoreticky je sice Web of Trust bezpečnějšíVycházíte z předpokladu, že nejbezpečnější je to, co si člověk udělá sám. Ten předpoklad je ovšem mylný.
Aby GPG bylo použitelné, tak by prostě muselo fungovat stejně, jako třeba HTTPS. Někde v GUI by byl zelený zámeček a implicitní mechanismy (např. TOFU) by poskytly nějaké rozumné zabezpečení pro každodenní použití s tím, že by bylo možné nějaké další ověření, pokud je k tomu důvod. Třeba "Like" na Facebooku by mohl zahrnovat podepsání klíče, pokud už se dané entity znají (např. provedeným nákupem v e-shopu). Nebo třeba při předání kontaktu pomocí NFC (kdyby to opravdu fungovalo). Ale ty nástroje by musely být opravdu jednoduché a přirozené, aby jejich použití bylo velmi snadné a probíhalo třeba i na pozadí bez zásahů uživatele.Tohle by sice bylo dotažení toho, jak se dnes web of trust používá, ale zároveň by to bylo ještě další oslabení bezpečnosti. Už dneska je ověření identity při podepisování v rámci web of trust žádné nebo velmi slabé (slabší než u běžných PKI autorit a podstatně slabší, než u těch opravdu důvěryhodných, např. akreditovaných). Takže je zřejmé, že u toho tvrzení „teoreticky je web of trust bezpečnější“ v té teorii něco podstatného chybí.
Citation needed. Pokud bude Web of Trust o nulové velikosti, tak degraduje na prosté TOFU, což je sice na první připojení horší než certifikační autority, ale na každé dalsí spojení mnohem bezpečnější. Web of Trust si vynucuje ověřování a řešení důvěryhodnosti. Oproti tomu certifikační autority jsou za důvěryhodné považovány všechny, takže se důvěryhodnost konkrétního klíče/certifikátu neřeší a kdokoliv mi může kdykoliv cokoliv podvrhnout, jen musí napřed navštívit nějakou mizernou autoritu. Dobrý příklad je SSH. Tam se to při prvním spojení zeptá zda sedí fingerprint a pak to nadává, pokud se klíč změní. Pokud by ten fingerprint byl na začátku uložen v DNS a/nebo podepsán autoritou, tak by to zlepšilo důvěryhodnost i při prvním připojení. Techniky jako certificate pinning se snaží TOFU dostat i do HTTPS, ale stále to je v plenkách a není to moc rozšířené.Teoreticky je sice Web of Trust bezpečnějšíVycházíte z předpokladu, že nejbezpečnější je to, co si člověk udělá sám. Ten předpoklad je ovšem mylný.
Pokud bude Web of Trust o nulové velikosti, tak degraduje na prosté TOFU, což je sice na první připojení horší než certifikační autority, ale na každé dalsí spojení mnohem bezpečnější.TOFU samozřejmě můžete použít i s PKI. Při použití TOFU je každé další spojení stejně bezpečné, jako to první – tím, že se připojíte podruhé, se bezpečnost logicky nemůže nijak zvýšit.
Web of Trust si vynucuje ověřování a řešení důvěryhodnosti.Jak si to vynucuje? Co mi zabrání bez rozmýšlení podepsat nějaký klíč?
Oproti tomu certifikační autority jsou za důvěryhodné považovány všechny, takže se důvěryhodnost konkrétního klíče/certifikátu neřeší a kdokoliv mi může kdykoliv cokoliv podvrhnout, jen musí napřed navštívit nějakou mizernou autoritu.Nestačí mizernou autoritu navštívit, je potřeba od ní získat certifikát. Standardy i těch nejhorších certifikačních autorit jsou pořád mnohem vyšší, než standardy běžných uživatelů PGP. A to nemluvím o akreditovaných certifikačních autoritách, ty jsou na tom ještě o hodně lépe.
Dobrý příklad je SSH. Tam se to při prvním spojení zeptá zda sedí fingerprint a pak to nadává, pokud se klíč změní. Pokud by ten fingerprint byl na začátku uložen v DNS a/nebo podepsán autoritou, tak by to zlepšilo důvěryhodnost i při prvním připojení.Ano, SSH je dobrý příklad. Kolik procent lidí si ty otisky reálně kontroluje? Pokud je otisk na začátku uložen v DNS a/nebo podepsán autoritou, nezlepší to důvěryhodnost jen při prvním připojení, ale při všech. Protože důvěryhodnost všech následujících připojení je závislá na důvěryhodnosti toho prvního připojení.
Techniky jako certificate pinning se snaží TOFU dostat i do HTTPS, ale stále to je v plenkách a není to moc rozšířené.Web of trust, certifikační autority a TOFU jsou tři konkurenční modely – někdy se mohou doplňovat a někdy si naopak překáží. TOFU se hodí tam, kde se komunikuje s omezeným okruhem adresátů. Pokud máte jeden SSH server a přidáváte jednoho klienta ročně, není problém jednou za rok ten otisk pečlivě zkontrolovat. Když budete mít ty servery někdo v cloudu a vznikne jich několik denně, už to žádná výhra nebude. Mimochodem, všimněte si, jak je to v OpenSSH implementováno – zobrazí vám otisk klíče a nechá vás to potvrdit. Takže to můžete odmáčknout bez jakékoli kontroly – a počítá se s tím, že to tak spousta lidí bude dělat. Přitom by bylo triviální vynucovat ověření klíče – prostě byste musel ten otisk odněkud opsat, klient by vám ho nezobrazil. Jen by to,co jste napsal, s otiskem porovnal. To by bylo podstatně bezpečnější – akorát o to skoro nikdo nestojí. V případě HTTPS komunikujete každou chvíli s novým serverem, takže je TOFU nepoužitelné. Certificate pinning se nidky ani moc nerozšíří, protože to je přesně ten případ, kdy jde TOFU proti těm dvěma konkurenčním modelům (web of trust i certifikační autority). Oba dva modely totiž počítají s tím,že důvěřujete něčemu jinému, než koncovému klíči – takže ty klíče se mohou snadno měnit. Nastartuje nový server v cloudu a vygeneruje si nový klíč. Server se ukončí a klíč se zahodí. Certificate pinning je pak k ničemu, protože budete akorát pořád ověřovat nové klíče.
fungování kvalifikovaných certifikátů (nebo jak přesně to právníci nazvali) je hodně odlišné od toho, jak se PKI běžně používá v prohlížečích a MUAV čem se to hodně liší? V obou případech mi někdo nadiktoval seznam autorit, kterým musím věřit. Rozdíl je jenom v tom, že v tom prohlížeči nebo MUA si ten seznam můžu upravit, kdybych chtěl.
to, že se openpgp model nehodí pro široké masy, ani zdaleka neznamená, že je špatně navržený; prostě je jen navržený pro jiné účely a jiné prostředí, kde funguje naopak výrazně lépe.Já jsem nikde nepsal, že je model web of trust špatně navržený. Polemizuju s tím, že není vhodný pro široké masy. Problém není v širokých masách, problém je v tom, že se ten model hodí jen do nějaké komunity. PGP klidně mohou používat zahrádkáři, a vůbec bych se nedivil, kdyby existovaly komunity mimo IT, kde se PGP používá.
Obávám se, že takdy se prostě neshodneme, protože zrovna ten příklad, který jste sám vybral, to ilustruje dost názorněJá jsem ovšem nepsal, že každé bezpečnější řešení je automaticky i pohodlné. Psal jsem jen to, že ta bezpečná řešení se často dají udělat mnohem pohodlnější. Jenomže je obvykle vymýšlejí experti na bezpečnost, kteří ovšem vůbec neberou v úvahu chování lidí. Pak z toho vznikají takové nesmysly, jako nutnost pravidelné změny hesla. Což je zrovna příklad toho, co píšu – když nutnost pravidelné změny hesla zrušíte, dostanete podstatně pohodlnější řešení, a je stejně bezpečné, možná o fous bezpečnější, protože bude menší tlak na uživatele, aby si volili slabá hesla. Další příklad jsou správci hesel – je to pohodlnější, než si hesla pamatovat, a podstatně bezpečnější. Podobně třeba přihlašování tokenem, čipovou kartou nebo U2F.
Tato věta je obsahově prázdná, pokud neřeknete, oproti čemu ji má zvyšovat. Oproti tomu, když se identita nebude ověřovat vůbec, rozhodně ano, ale to není moc vysoko nastavená laťka. Oproti web of trust modelu provozovanému dostatečně informovanými a zodpovědnými uživateli… ani náhodou.Myslel jsem si, že je jasné, že porovnáváme ověření identity certifikační autoritou a ověření identity jednotlivcem. Ano, pokud budou web of trust provozovat dostatečně informovaní a zodpovědní lidé, bude to stejně bezpečné, jako když to ověřuje akreditovaná certifikační autorita. Ti lidé musí být například informovaní o tom, jak správně ověřit doklady totožnosti. A zároveň si musí být jistí, že stejně dobře postupují i ti, jejichž podpisům věří. Víte, jak početná je síť takových uživatelů? Přesně 0 osob.
V čem se to hodně liší?
Jak v tom, jak důkladně se ověřuje identita žadatele, tak v tom, jak komplikované je takový certifikát získat. Ono to pak totiž najednou už není podstatně jednodušší než získat podpisy pro web of trust. (Pokud to vůbec je jednodušší - pro každého určitě ne.)
Pak z toho vznikají takové nesmysly, jako nutnost pravidelné změny hesla.
Což už skuteční experti - včetně oficiálních organizací - nějaký ten pátek nedoporučují.
Další příklad jsou správci hesel – je to pohodlnější, než si hesla pamatovat, a podstatně bezpečnější.
Pro méně důležitá hesla ano. Ta opravdu důležitá bych takovému správci nesvěřil.
Podobně třeba přihlašování tokenem, čipovou kartou nebo U2F.
Už sama potřeba si takový token nebo kartu pořídit (úplně zadarmo to není), na jedné straně ho mít po ruce, když je potřeba, a na druhé dávat pozor, aby se nedostal do nepovolaných rukou, to pohodlí do značné míry eliminuje. Takže za opravdu pohodlnější bych si to troufl označit až od takové míry nároků na bezpečnost, která se většiny uživatelů netýká.
Myslel jsem si, že je jasné, že porovnáváme ověření identity certifikační autoritou a ověření identity jednotlivcem. … Přesně 0 osob.
Jak jsem řekl, na tomhle se prostě neshodneme. Pro mne je třeba web of trust kolem linuxového jádra podstatně důvěryhodnější než ta šílená sada "důvěryhodných" certifikačních autorit, kterou mi Mozilla Foundation nasypala do Firefoxu.
Celkově je mi ale především moc smutno z toho, že je to v krátké době už druhý blog, u kterého byla diskuse místo technických témat a praktických zkušeností, které by mohly být leckomu užitečné, hijacknuta na neplodný flame na téma "je to vlastně vůbec k něčemu?" Tímto se omlouvám za svůj podíl a pokusím se v tom dále nepokračovat.
28.5.2020 22:57
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
Což už skuteční experti - včetně oficiálních organizací - nějaký ten pátek nedoporučují.Ano, akorát se to v oboru drželo přes dvacet let. A u těch oficiálních organizací se to dá opravdu počítat na pátky, kdy to přestaly doporučovat.
Pro méně důležitá hesla ano. Ta opravdu důležitá bych takovému správci nesvěřil.To je další z problémů počítačové bezpečnosti. Pokud už se tím někdo trošku začne zabývat, obvykle hrozně přeceňuje sám sebe a podceňuje vše ostatní. Pak z toho vznikají takové bludy, jako že web of trust je teoreticky bezpečnější než certifikační autorita nebo že pamatovat si heslo je bezpečnější, než používat správce hesel.
Už sama potřeba si takový token nebo kartu pořídit (úplně zadarmo to není), na jedné straně ho mít po ruce, když je potřeba, a na druhé dávat pozor, aby se nedostal do nepovolaných rukou, to pohodlí do značné míry eliminuje. Takže za opravdu pohodlnější bych si to troufl označit až od takové míry nároků na bezpečnost, která se většiny uživatelů netýká.Dostupnost se bude postupně zlepšovat, teď jsme úplně na začátku. Dávat pozor, aby se nedostal do nepovolaných rukou, je snazší, než u hesla – resp. u hesla to skoro nikdo neřeší nějak aktivně, stejně tak to nebudou aktivně řešit lidé u tokenů a U2F. A pasivní bezpečnost (že to vyloženě někomu nestrkám pod nos) je u tokenů a U2F na mnohem vyšší úrovni. Oproti přihlašování heslem, které si uživatel pamatuje, je používání tokenu nebo U2F určitě pohodlnější.
Pro mne je třeba web of trust kolem linuxového jádra podstatně důvěryhodnější než ta šílená sada "důvěryhodných" certifikačních autorit, kterou mi Mozilla Foundation nasypala do Firefoxu.Lidé kolem linuxového jádra jsou pořád komunita. A upřímně řečeno, odolnost téhle komunitu proti náhodnému útočníkovi, je podstatně menší, než odolnost i těch nejhorších certifikačních autorit ve Firefoxu. Problém toho seznamu certifikačních autorit jsou různé čínské a podobné autority, které budou mít problémy s útoky svých vlád. Což mne v současné situaci nemusí tolik trápit (ano, je to sobecké).
Celkově je mi ale především moc smutno z toho, že je to v krátké době už druhý blog, u kterého byla diskuse místo technických témat a praktických zkušeností, které by mohly být leckomu užitečné, hijacknuta na neplodný flame na téma "je to vlastně vůbec k něčemu?" Tímto se omlouvám za svůj podíl a pokusím se v tom dále nepokračovat.Nemyslím si, že bychom v tomhle vlákně diskutovali o tom, zda je to vůbec užitečné. Diskutujeme o tom, jaké to má vlastnosti a k čemu to tedy užitečné je a k čemu už ne. Za mne je PGP užitečné v tom, že je to hezký systém na výměnu klíčů, přičemž důvěryhodnost klíčů není zabudována přímo v tom systému – což je podle mne klíčová vlastnost a je chyba tvářit se, že je tam zabudovaná. Ale ve spoustě případů stačí TOFU, ve spoustě případů se dá klíč bezpečně předat jiným způsobem (což je třeba případ nejčastěji používaných asymetrických klíčů – pro DV certifikáty, kde se kvůli PKI provozuje drahý byznys tam, kde by stačilo zveřejňovat klíče v DNS). Ale web of trust bych rozhodně nevyzdvihoval jako přednost PGP, protože je to z hlediska bezpečnosti velmi přeceňované a reálná bezpečnost je na úrovni TOFU, možná o kousínek výš.
BTW: Spoustu těch odkazů máš blbě, protože ti tam vlezly nějaké uvozovky.Dík, co jsem našel, jsem opravil.
28.5.2020 12:35
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
29.5.2020 00:05
$ gpg --gen-key
gpg (GnuPG) 1.4.20; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gpg: directory `/home/mint/.gnupg' created
gpg: new configuration file `/home/mint/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/mint/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/home/mint/.gnupg/secring.gpg' created
gpg: keyring `/home/mint/.gnupg/pubring.gpg' created
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
< n> = key expires in n days
< n>w = key expires in n weeks
< n>m = key expires in n months
< n>y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) < heinrichh@duesseldorf.de >"
Real name: plostenka
Email address:
Comment: test
You selected this USER-ID:
"plostenka (test)"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
...+++++
Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 202 more bytes)
gpg: /home/mint/.gnupg/trustdb.gpg: trustdb created
gpg: key A6241D0C marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub 4096R/A6241D0C 2020-05-28
Key fingerprint = 75C2 C03C 1B3E 61B8 E606 47F5 BBFE D597 A624 1D0C
uid plostenka (test)
sub 4096R/5E65E357 2020-05-28
HOTOVO. A muzu klic pouzivat. Bezny uzivatel nepotrebuje rozlisovat podklice, chce jen posilat maily/soubory tak, aby je nemohla precist treti strana (zasifrovanim klicem prijemce), a nebo aby prijemce vedel kdo je autor (podepsanim vlastnim klicem). Mutt/Thunderbird/Evolution GPG podporuji, neni problem. A jak rika predrecnik, neexistuje alternativa ktera by nevynucovala duveru k master klici, ktery nemam pod kontrolou (PKI a webove "autority").
28.5.2020 22:20
Petr Fiedler | skóre: 35
| blog: Poradna
| Brno
Super zápis, díky.
jsem se ke KMail už nevrátil, takže nevím jak a jestli to tam je implementováno i teď. Každopádně je mi ten koncept mnohem bližší, než "slavné" certifikáty.
Tak ještě nápověda pro ty, kdo by chtěli vyzkoušet použití gpg klíče pro ssh autentizaci a podle návodů na webu (např. [1], [2], [3]) to nefunguje. Zdá se, že většina návodů je psaných pro starší verze gpg a nepočítá s user friendly prostředími typu KDE, kde se gpg-agent spouští globálně pro celé prostředí.
Takhle mi to funguje s openSUSE Leap 15.2 (gpg 2.2.5):
[A]) subkey nebo přidat tuto funkci existujícímu.gpg --export-ssh-key <id>" vyexportovat veřejný klíč v ssh kompatibilním formátu a řádek přidat na server do authorized_keys; jako <id> lze použít id autentizačního klíče, id master klíče (stejně se exportuje autentizační) nebo třeba e-mail.enable-ssh-support" do ~/.gnupg/gpg-agent.conf (pokukd neexistuje, vytvořit ho).SSH_AUTH_SOCK do ~/.bashrc a restartu gpg-agent (tedy kill a buď spustit ručně nebo doufat, že se to udělá automaticky); pokud máte gpg-agent spuštěný při startu desktopového prostředí, nemusí to fungovat dobře, takže se mi spíš osvědčilo ukončit session a přihlásit se znovu. (Tohle všechno se stejně dělá jen jednou.)~/.gnupg by se měl objevit soubor sshcontrol, do kterého je potřeba přidat řádek s gripem každého klíče, který se bude používat pro autentizaci ("gpg --list-keys --with-keygrip <id>"). Všechny ostatní totiž bude gpg-agent ignorovat.ssh-add -l" nebo "ssh-add -L" klíč ukázat.authorized_keysCelé to má smysl hlavně pokud je openpgp klíč v tokenu nebo kartě, jinak je obvykle jednodušší použít nativní ssh klíč a ssh-agent.
30.5.2020 19:41
Petr Fiedler | skóre: 35
| blog: Poradna
| Brno
Díky. I za ostatní příspěvky. Dobrý zdroj informací.
tak jako GPG je cool a vsechno, ale pokud mi za 20 let neprisel jediny mail zasifrovany mym verejnym klicem, tak pouzitelnost pro email v praxi nulova...
ze muzu mail podepsat svym klicem je super, kdyby to bylo v praxi jak overit...
zasifrovane soubory ani nemuzu jednoduse sdilet, protoze to 99.9x% populace neotevre
na sifrovani souboru na disku jsou pohodlnejsi varianty, treba LUKS pro cely filesystem
k cemu to GPG vlastne *prakticky* je? (chapu, ze ty body nahore nejsou vina toho programu)
30.5.2020 10:45
Petr Fiedler | skóre: 35
| blog: Poradna
| Brno
Řekl bych, že je to pro rozumné a zasvěcené lidi, kteří mezi sebou chtějí komunikovat bez ztráty soukromí. Ale takových je málo. Většina je líná se něco učit a někteří z nich na FB fotí i to, co večeřeli.
30.5.2020 10:47
Petr Fiedler | skóre: 35
| blog: Poradna
| Brno
Samozřejmě mimo jiné. Já se vyjadřoval k mejlům.
30.5.2020 17:21
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
Jak ty "zlé", tak ty "hodné":
mike@lion:~> gpg --version
gpg (GnuPG) 2.2.5
libgcrypt 1.8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: /home/mike/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
Tiskni
Sdílej:
