From codeguro at gmail.com Sat Jun 1 00:27:17 2019 From: codeguro at gmail.com (Tony Lane) Date: Fri, 31 May 2019 18:27:17 -0400 Subject: Encryption Algorithm for GnuPG? In-Reply-To: <8b66ae97-1117-8ead-3aea-4778b6706aa7@sixdemonbag.org> References: <2849561439a8a908889eaa2f3f7a5e5f@smtp.hushmail.com> <8b66ae97-1117-8ead-3aea-4778b6706aa7@sixdemonbag.org> Message-ID: I would say chacha2020 is also a strong cipher up there with AES. The fact that AES uses lookup table with an index derived from the secret makes general implementations vulnerable to cache-timing attacks. ChaCha20 is not vulnerable to such attacks. (AES implemented through AES-NI is also not vulnerable, but I don?t know if GPG?s implementation of it uses that) It also has the benefit of being made by Daniel J. Bernstein which is the same guy who formulated the Ed25519 curve and fought off the US government in court in declassifying elliptic curve crypto from being a military munition. You can see the rfc for the algorithms here: https://tools.ietf.org/html/rfc7539 On May 31, 2019, at 11:58 AM, Robert J. Hansen wrote: >> What is the encryption engine for the current GnuPG. > > By default, AES. Other algorithms are possible but not recommended. > The only other algorithms I'd recommend are Twofish and Camellia. > >> I know IDEA is proprietary so that can?t be used > > It can be used. You'd be insane to actually use it, but that doesn't > change the fact it can be used. > > IDEA was broken in 2011-2012 using meet-in-the-middle attacks and a > bicliques attack. These aren't attacks on reduced-round variants of > IDEA. This is the full-strength algorithm has been found vulnerable to > at least two different methods of cryptanalysis. Right now those > attacks aren't terribly significant -- they shave a few bits off the > strength of the cipher -- but those attacks will only get better over time. > > I'm unaware of any cryptographer who's still seriously studying IDEA. > It's considered to have taken a hit below the waterline. Please do not > use IDEA for generating new traffic. Please only use IDEA to read > existing traffic. > >> If it?s NIST AES that is under the US Government? > > No. It's a Belgian-designed algorithm with no connection to the United > States government. This algorithm, called "Rijndael", works with a > variety of block sizes and key sizes. > > All the United States government did was say "Rijndael with a 128-bit > block size will be our new Advanced Encryption Standard, and AES will > support key sizes of 128, 192, and 256 bits." > > That's it. > >> Wouldn?t that be in danger of a US back door in the algorithm? > > No. An excellent reason to believe there is no back door comes from the > fact the United States government uses AES to secure its most > confidential information -- it's one of the few algorithms that's > certified for use at the Top Secret level. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sat Jun 1 05:53:13 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 31 May 2019 23:53:13 -0400 Subject: Encryption Algorithm for GnuPG? In-Reply-To: References: <2849561439a8a908889eaa2f3f7a5e5f@smtp.hushmail.com> <8b66ae97-1117-8ead-3aea-4778b6706aa7@sixdemonbag.org> Message-ID: <707fd8a2-304f-9919-0fcf-8dc95e68b7ce@sixdemonbag.org> Please don't send HTML email to this list. On 5/31/19 6:27 PM, Tony Lane wrote: > I would say chacha2020 is also a strong cipher up there with AES. As soon as you get ChaCha20 added to the OpenPGP spec, I'll start participating in discussions on this mailing list about its merits. :) > It also has the benefit of being made by?Daniel J. Bernstein... Although djb definitely has cryptographer cred, you're doing yourself no favors by not noting the pedigree of AES. Vincent Rijmen is one of the sharpest cryptographers in the world today, and Joan Daemen is also better known as the guy who invented Keccak. Their errors are literally more interesting than most other people's successes. djb is definitely a smart guy. But there are lots of smart people bouncing around the crypto field -- and we are all so lucky that's the case! From wolfgang.traylor at posteo.de Sat Jun 1 10:28:06 2019 From: wolfgang.traylor at posteo.de (Wolfgang Traylor) Date: Sat, 1 Jun 2019 10:28:06 +0200 Subject: missing root certificate, SMIME spanish government In-Reply-To: <87v9xqsp0w.fsf@mat.ucm.es> References: <87v9xqsp0w.fsf@mat.ucm.es> Message-ID: <20190601082804.bvub3dr5tnhyl5ks@gruenfink> Hello Uwe Brauer, > I installed all its root certificates in > /usr/share/ca-certificates/Spain I usually put the fingerprint of the root certificate in ~/.gnupg/trustlist.txt like this: ``` # CN=COMODO RSA Certification Authority # O=COMODO CA Limited # L=Salford # ST=Greater Manchester # C=GB # Checked fingerprint here: https://developer.visa.com/pages/trusted_certifying_authorities AF:E5:D2:44:A8:D1:19:42:30:FF:47:9F:E2:F8:97:BB:CD:7A:8C:B4 S relax ``` -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From oub at mat.ucm.es Sat Jun 1 12:14:00 2019 From: oub at mat.ucm.es (Uwe Brauer) Date: Sat, 01 Jun 2019 12:14:00 +0200 Subject: missing root certificate, SMIME spanish government References: <87v9xqsp0w.fsf@mat.ucm.es> <20190601082804.bvub3dr5tnhyl5ks@gruenfink> Message-ID: <87imtpvcif.fsf@mat.ucm.es> >>> "WT" == Wolfgang Traylor writes: Hello > Hello Uwe Brauer, >> I installed all its root certificates in >> /usr/share/ca-certificates/Spain > I usually put the fingerprint of the root certificate in ~/.gnupg/trustlist.txt like this: > ``` > # CN=COMODO RSA Certification Authority > # O=COMODO CA Limited > # L=Salford > # ST=Greater Manchester > # C=GB > # Checked fingerprint here: https://developer.visa.com/pages/trusted_certifying_authorities > AF:E5:D2:44:A8:D1:19:42:30:FF:47:9F:E2:F8:97:BB:CD:7A:8C:B4 S relax > ``` That is what I tried. However given a cer file, how can I find out its fingerprint? In any case I finally solveed the issue by just importing all available cer into gpgsm and it worked, by mistake was to assume that gpgsm uses the ones which are installed system wide. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4393 bytes Desc: not available URL: From wolfgang.traylor at posteo.de Sat Jun 1 12:55:54 2019 From: wolfgang.traylor at posteo.de (Wolfgang Traylor) Date: Sat, 1 Jun 2019 12:55:54 +0200 Subject: missing root certificate, SMIME spanish government In-Reply-To: <87imtpvcif.fsf@mat.ucm.es> References: <87v9xqsp0w.fsf@mat.ucm.es> <20190601082804.bvub3dr5tnhyl5ks@gruenfink> <87imtpvcif.fsf@mat.ucm.es> Message-ID: <20190601105553.32n44h5zcyz5zg2h@gruenfink> > However given a cer file, how can I find out its fingerprint? This command will show you the details of the certificates from the website[1] you mentioned including its fingerprint: openssl x509 -noout -text -fingerprint -inform DER -in downloaded_key_file.cer Or you import the key with `gpgsm --import file.cer` and look in the list of `gpgsm --list-keys`. [1] https://www.sede.fnmt.gob.es/descargas/certificados-raiz-de-la-fnmt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From oub at mat.ucm.es Sat Jun 1 14:49:29 2019 From: oub at mat.ucm.es (Uwe Brauer) Date: Sat, 01 Jun 2019 14:49:29 +0200 Subject: missing root certificate, SMIME spanish government References: <87v9xqsp0w.fsf@mat.ucm.es> <20190601082804.bvub3dr5tnhyl5ks@gruenfink> <87imtpvcif.fsf@mat.ucm.es> <20190601105553.32n44h5zcyz5zg2h@gruenfink> Message-ID: <87pnnxa2sm.fsf@mat.ucm.es> >>> "WT" == Wolfgang Traylor writes: >> However given a cer file, how can I find out its fingerprint? > This command will show you the details of the certificates from the website[1] > you mentioned including its fingerprint: > openssl x509 -noout -text -fingerprint -inform DER -in downloaded_key_file.cer Thanks > Or you import the key with `gpgsm --import file.cer` and look in the list of > `gpgsm --list-keys`. Well but if I import the key, then I don't need to add it to the trustedlist file -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5025 bytes Desc: not available URL: From angel at pgp.16bits.net Sun Jun 2 23:46:57 2019 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 02 Jun 2019 23:46:57 +0200 Subject: Is limit-card-insert-tries a working option? In-Reply-To: <20190531175306.fc26nqqyjhzomnqj@chipsenkbei-mbp.dhcp.thefacebook.com> References: <20190529145631.5pgrqhdxdm5u3zlt@chipsenkbei-mbp> <20190530160001.oba6qhcwn6q7yyiy@chipsenkbei-mbp.dhcp.thefacebook.com> <053ff3cb-d1d8-cb8f-e27a-bd98fd73bd75@gmail.com> <20190531175306.fc26nqqyjhzomnqj@chipsenkbei-mbp.dhcp.thefacebook.com> Message-ID: <1559512017.922.10.camel@16bits.net> I would say, why are you encrypting to the three subkeys? In your original mail this stood up: > The annoyance comes from the pinentry prompt I'm using with the gpg > agent. When needing to refresh the cache, the agent prompts me > multiple times to insert my other smart cards before it reaches the > smart card that is currently plugged into my device. This happens on > both OSX and Fedora using version 2.2.15 of gpg and gpg-agent. as it should be asking just for the needed key. However, since for encryption you are using: > gpg2 -e -r keyid1! -r keyid2! -r keyid3! -o content.gpg --quiet --yes --compress-algo=none --no-encrypt-to --batch --use-agent /path/to/content.txt and you do have those three keys, it is asking for all of them. So I would recommend you to use just one of them. Or, if you really want to encrypt to the three subkeys (for backup?), not to use the three of them on the same computer. So that you would only have imported one of the secret keys (imported as in known by the secret keyring that it it there on a smartcard) Having three sets of subkeys on your key is weird > -------------------------------------- > sec rsa4096/0x6CA6A08DBA640677 2019-03-01 [SC] > 2C8160E6AF1166154CDAED266CA6A08DBA640677 > uid [ultimate] Chip Senkbeil (My mail & pass key) > ssb> rsa4096/0x588B4B090695884C 2019-03-01 [E] > ssb> rsa4096/0x8A6B3DB2C23EB74B 2019-05-08 [E] > ssb> rsa4096/0x95B67753BA414327 2019-05-08 [E] > ssb> rsa4096/0x231C4CB425985243 2019-05-28 [S] [expires: 2024-05-26] > ssb> rsa4096/0x1F3D585E398D11B1 2019-05-28 [S] [expires: 2024-05-26] > ssb> rsa4096/0x5487424ABA6BDDDB 2019-05-28 [S] [expires: 2024-05-26] > ssb> rsa4096/0x68F5987A509841B2 2019-05-28 [A] [expires: 2024-05-26] > ssb> rsa4096/0x70B8AA34DA9D2413 2019-05-28 [A] [expires: 2024-05-26] > ssb> rsa4096/0xDD69ABE5B8BCF75C 2019-05-28 [A] [expires: 2024-05-26] > -------------------------------------- and it is likely to confusing when people write you (per Murphy's law they will probably use for encryption the one you don't have with you). You know you could have the same subkeys on three different yubikeys, do you? Kind regards From wk at gnupg.org Mon Jun 3 12:22:12 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Jun 2019 12:22:12 +0200 Subject: missing root certificate, SMIME spanish government In-Reply-To: <87pnnxa2sm.fsf@mat.ucm.es> (Uwe Brauer's message of "Sat, 01 Jun 2019 14:49:29 +0200") References: <87v9xqsp0w.fsf@mat.ucm.es> <20190601082804.bvub3dr5tnhyl5ks@gruenfink> <87imtpvcif.fsf@mat.ucm.es> <20190601105553.32n44h5zcyz5zg2h@gruenfink> <87pnnxa2sm.fsf@mat.ucm.es> Message-ID: <87woi3vui3.fsf@wheatstone.g10code.de> On Sat, 1 Jun 2019 14:49, oub at mat.ucm.es said: > Well but if I import the key, then I don't need to add it to the > trustedlist file The trustlist.txt list those certificates which are valid as root certificates. Importing a certificate does not add it to this list for obvious reasons: All kind of certificates are imported all the time without the user noticing (e.g. those sent as part of an S/MIME mail). Root certificates are the trust anchor and thus we need the user's consent to use them in such a way. By default gpgsm asks you whether a certificate, which technically can act as root certificate, shall be granted the trusted status (i.e. used as a root certificate by being added to trustlist.txt). You can change this default by adding "no-allow-mark-trusted" to gpg-agent.conf. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From emordin at protonmail.com Mon Jun 3 18:11:04 2019 From: emordin at protonmail.com (emordin) Date: Mon, 03 Jun 2019 16:11:04 +0000 Subject: [gpg4win-3.1.7] Automated Import of Public Key between programs Message-ID: I'm learning to use OpenPGP on Windows and I downloaded the gpg4win-3.1.7 package which contains: GnuPG 2.2.15 Kleopatra 3.1.7 GPA 0.10.0 GpgOL 2.3.3 GpgEX 1.0.6 Kompendium (de) 4.0.1 Compendium (en) 3.0.0 I installed GnuPG, Kleopatra (certificate manager), GPA (graphical manager of keys), and GpgEX (GnupG extension for Windows Explorer)... My question is when i use programs like Enigmail or the Mailvelop browser plugin, my public keys get automatically imported to those programs. Is this a feature of GnuPG on all OS's (Linux, etc.) or is this only a feature on Windows? If this is a feature for GnuPG, does anyone know what daemon/service is running this? And if there is any documentation online to how this process works? Thanks. Sent with [ProtonMail](https://protonmail.com) Secure Email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Mon Jun 3 19:22:17 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 3 Jun 2019 13:22:17 -0400 Subject: [gpg4win-3.1.7] Automated Import of Public Key between programs In-Reply-To: References: Message-ID: Please don't send HTML email to this list. > manager of keys), and GpgEX (GnupG extension for Windows Explorer)... My > question is when i use programs like Enigmail or the Mailvelop browser > plugin, my public keys get automatically imported to those programs. Enigmail doesn't. Enigmail uses GnuPG behind-the-scenes, so any key GnuPG knows about, Enigmail knows about. Enigmail has precisely zero crypto code itself (although that's slowly changing as we give more thought to OpenPGP.js). From emordin at protonmail.com Mon Jun 3 18:03:56 2019 From: emordin at protonmail.com (emordin) Date: Mon, 03 Jun 2019 16:03:56 +0000 Subject: [gpg4win-3.1.7] Automated importing of public keys Message-ID: I'm learning to use PGP on Windows and I downloaded the gpg4win-3.1.7 package which contains: [GnuPG](https://www.gnupg.org/) 2.2.15 [Kleopatra](https://www.kde.org/applications/utilities/kleopatra/) 3.1.7 [GPA](https://www.gnupg.org/related_software/gpa/index.html) 0.10.0 [GpgOL](https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgol.git;a=summary) 2.3.3 [GpgEX](https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgex.git;a=summary) 1.0.6 [Kompendium (de)](https://www.gpg4win.org/doc/de/gpg4win-compendium.html) 4.0.1 [Compendium (en)](https://www.gpg4win.org/doc/en/gpg4win-compendium.html) 3.0.0 I installed GnuPG, Kleopatra (certificate manager), GPA (graphical manager of keys), and GpgEX ( GnupG extension for the Windows Explorer)... My question is when I use programs like Enigmail or the Mailvelope browser plugin, my public key gets automatically imported to those programs. Is this a feature of GnuPG on all OS's (Linux,etc) or is this only a feature on Windows? If this is a feature for GnuPG, does anyone know what daemon/service is running this? And if there is any documentation online to how this process works? Thanks. Sent with [ProtonMail](https://protonmail.com) Secure Email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chip.senkbeil at gmail.com Tue Jun 4 14:42:47 2019 From: chip.senkbeil at gmail.com (Chip Senkbeil) Date: Tue, 4 Jun 2019 07:42:47 -0500 Subject: Is limit-card-insert-tries a working option? In-Reply-To: <1559512017.922.10.camel@16bits.net> References: <20190529145631.5pgrqhdxdm5u3zlt@chipsenkbei-mbp> <20190530160001.oba6qhcwn6q7yyiy@chipsenkbei-mbp.dhcp.thefacebook.com> <053ff3cb-d1d8-cb8f-e27a-bd98fd73bd75@gmail.com> <20190531175306.fc26nqqyjhzomnqj@chipsenkbei-mbp.dhcp.thefacebook.com> <1559512017.922.10.camel@16bits.net> Message-ID: <20190604124247.i3axasa7o6t7zzu5@chipsenkbei-mbp.dhcp.thefacebook.com> Hey ?ngel, thanks for the reply! My setup is that I have multiple computers: two work laptops, a personal laptop, a desktop, and a cell phone. I'd originally used a private key to purely do encryption of my passwords on one of my work laptops, replacing lastpass with the pass utility from passwordstore.org. The pass tool stores each of your passwords in a separate, encrypted file on your computer, where the recipients are whatever encryption IDs you provide. Originally, this was just the one encryption subkey I had. When I wanted to use my password manager on other computers, I needed to have an appropriate subkey available. Initially, I was just going to copy around the same subkey, but I had the problem that the password manager utility on my phone would also need the subkey and I didn't want to copy over a private subkey onto my phone directly. Then I learned that smart cards could store encryption, authentication, and signing keys. I already had one Yubikey at work for one-touch passwords, so figured I'd give that a go. >From what I've read from others' experiences, you generally put a unique subkey on a smartcard and copying the same subkey around isn't well supported. At least, not to my knowledge. https://dev.gnupg.org/T2291 highlights the main issue with copying keys in that the stub generated also has the card's ID associated with it and - presently - gnupg doesn't support multiple card IDs or anything like that. So you'd be prompted for a different smart card even if you had a smart card with the same encryption subkey, right? Just want to make sure I understand that issue properly. I've been using the authentication subkeys just fine for SSH and the signing subkeys also work for signing my git commits, but that's all I've used so far. I hadn't taken a look at encrypting my email just yet, although it was something on my backlog to do with neomutt eventually. There may be some issues with my approach and mail encryption, as you mentioned earlier. At this point, each of my computers ONLY has a single stub available with all of the other subkeys listed as offline (pound symbol), yet the gpg utility still selects the latest subkey (rather than the only one available) if I don't including the exclamation mark on the keys when encrypting with recipients. Here's an example now of what `gpg -K` outputs for me, minus a couple of additional subkeys I've generated for other devices. -------------------------------------- sec# rsa4096/0x6CA6A08DBA640677 2019-03-01 [SC] 2C8160E6AF1166154CDAED266CA6A08DBA640677 uid [ultimate] Chip Senkbeil (My mail & pass key) ssb> rsa4096/0x588B4B090695884C 2019-03-01 [E] ssb# rsa4096/0x8A6B3DB2C23EB74B 2019-05-08 [E] ssb# rsa4096/0x95B67753BA414327 2019-05-08 [E] ssb> rsa4096/0x231C4CB425985243 2019-05-28 [S] [expires: 2024-05-26] ssb# rsa4096/0x1F3D585E398D11B1 2019-05-28 [S] [expires: 2024-05-26] ssb# rsa4096/0x5487424ABA6BDDDB 2019-05-28 [S] [expires: 2024-05-26] ssb> rsa4096/0x68F5987A509841B2 2019-05-28 [A] [expires: 2024-05-26] ssb# rsa4096/0x70B8AA34DA9D2413 2019-05-28 [A] [expires: 2024-05-26] ssb# rsa4096/0xDD69ABE5B8BCF75C 2019-05-28 [A] [expires: 2024-05-26] -------------------------------------- How would you approach my setup? Thinking about it now, I really should have asked for advice on this mailing list before I got started to see what other people would do! Would love to know what you and others would do to leverage a unique smartcard per device (I've got one per laptop/desktop/phone) for encryption, etc. On Sun, Jun 02, 2019 at 11:46:57PM +0200, ?ngel wrote: > I would say, why are you encrypting to the three subkeys? > > > In your original mail this stood up: > > The annoyance comes from the pinentry prompt I'm using with the gpg > > agent. When needing to refresh the cache, the agent prompts me > > multiple times to insert my other smart cards before it reaches the > > smart card that is currently plugged into my device. This happens on > > both OSX and Fedora using version 2.2.15 of gpg and gpg-agent. > > as it should be asking just for the needed key. > > > However, since for encryption you are using: > > gpg2 -e -r keyid1! -r keyid2! -r keyid3! -o content.gpg --quiet --yes --compress-algo=none --no-encrypt-to --batch --use-agent /path/to/content.txt > > and you do have those three keys, it is asking for all of them. > > So I would recommend you to use just one of them. > > Or, if you really want to encrypt to the three subkeys (for backup?), > not to use the three of them on the same computer. So that you would > only have imported one of the secret keys (imported as in known by the > secret keyring that it it there on a smartcard) > > Having three sets of subkeys on your key is weird > > -------------------------------------- > > sec rsa4096/0x6CA6A08DBA640677 2019-03-01 [SC] > > 2C8160E6AF1166154CDAED266CA6A08DBA640677 > > uid [ultimate] Chip Senkbeil (My mail & pass key) > > ssb> rsa4096/0x588B4B090695884C 2019-03-01 [E] > > ssb> rsa4096/0x8A6B3DB2C23EB74B 2019-05-08 [E] > > ssb> rsa4096/0x95B67753BA414327 2019-05-08 [E] > > ssb> rsa4096/0x231C4CB425985243 2019-05-28 [S] [expires: 2024-05-26] > > ssb> rsa4096/0x1F3D585E398D11B1 2019-05-28 [S] [expires: 2024-05-26] > > ssb> rsa4096/0x5487424ABA6BDDDB 2019-05-28 [S] [expires: 2024-05-26] > > ssb> rsa4096/0x68F5987A509841B2 2019-05-28 [A] [expires: 2024-05-26] > > ssb> rsa4096/0x70B8AA34DA9D2413 2019-05-28 [A] [expires: 2024-05-26] > > ssb> rsa4096/0xDD69ABE5B8BCF75C 2019-05-28 [A] [expires: 2024-05-26] > > -------------------------------------- > > and it is likely to confusing when people write you (per Murphy's law > they will probably use for encryption the one you don't have with you). > > You know you could have the same subkeys on three different yubikeys, do > you? > > > Kind regards > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From 2017-r3sgs86x8e-lists-groups at riseup.net Tue Jun 4 21:28:29 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Tue, 4 Jun 2019 20:28:29 +0100 Subject: [gpg4win-3.1.7] Automated importing of public keys In-Reply-To: References: Message-ID: <1931561558.20190604202829@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 3 June 2019 at 5:03:56 PM, in , emordin via Gnupg-users wrote:- > Is this a feature of GnuPG on all > OS's > (Linux,etc) or is this only a feature on Windows? I have not used those specific front-end programs with GnuPG, but the ones I have used have all accessed GnuPG's keyrings behind the scenes rather than importing anything to a separate key store. - -- Best regards MFPA He who rests on his laurels wears them on wrong end. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXPbGdl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +g1RAQD8p2pZWXNpBWYX6o+gM+pv4bRyURPA9ZOj6EdV9lfihQEAqSxUKZWbv1Em H3EQeioZ40YU1iv/ki7HR04OFKQ1GQeJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXPbGdl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/9L1EACO1ysTqkp7uxwrCQ+o5tkDOJda BRYTbn5GrIpeDUMj5NzC00di32BJMlypcEuguo4Y41VlRgZIMctFmiq96EjjcOyS zf14DKKnb18cq/2AsnpxUuKYeTWkGkqzJ2TUqcf5aEGZ8QPHWzTL2zhjJu9Tp9Vs Ic7E8usIinJ46tk5kuILXMrRC9onOtqw+zRXG/ebJaRxn/nJBTtxKa6yoo+eRnLC +D98/ktSnJTrAcWRr845GQYVV10nJ2e88q42BMqL+p+qc0yNrpO6tMkYpZg9E8w8 1R75IFzHa5c6zvtVkhe3A7PeDr0Je85mgzBu3pcvuGYjzuip/QJNl/hyaD/a3YM2 /uCBXIEhjFnALxUd/heO0nbuTqid4fmZQJ/staznWgctp61aUo/wT2/3On++YETt YJMM4RJDvw10rd60S7mEkE/kUXnNaPuKkZNYdcNISZps/0EYIhmkI9O+B29illnN jGlGBUHglSyarWPT9LHSHit6O10fViZgPCauPFX5HjnMcG1JeAr5AMZuTq++VIsj rkN4PS7n7UPL114lTgpz1y4HojQR4UgkqyvYg6vhf1zJmC7rQhDOV6GFMqw5n86h vDbLUGeQgKJJVG3yCpeqN7OU5Ynt5j8Qd3RGO68YmIkx4obiNZZ/JD5jwasLw+VC XdcanmKQjTfvjqWfZQ== =geIf -----END PGP SIGNATURE----- From telegraph at gmx.net Wed Jun 5 19:10:57 2019 From: telegraph at gmx.net (Gregor Zattler) Date: Wed, 05 Jun 2019 19:10:57 +0200 Subject: how to integrate ca-certificates with gpgsm (for email s/mime signature verification) Message-ID: <87ef48t0ta.fsf@len.workgroup> Hi gnupg users and developers, , I use notmuch-emacs to read my email and sometimes do use GnuPG, therefore notmuch-emacs is configured to verify signatures but does so also for S/MIME signatures. When displaying such emails I'm asked if I trust the respective Root CAs Cert. That's tedious. Therefore I would like to integrate certificates provided by debians ca-certificates package with gpgsm, but the only way I found to do so, would be to manually import all those certificates. Isn't there an option to read in those certs from /etc/ssl... at start-up? Ciao; Gregor From wiktor at metacode.biz Fri Jun 7 16:18:55 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Fri, 7 Jun 2019 16:18:55 +0200 Subject: Adding notations with quick commands Message-ID: Hello, Is there a way to add notation to own key's User IDs with a quick command? I'm looking for an alternative to this set of actions: 1. gpg --edit-key $KEY 2. notation 3. xyz at example.com=test 4. save in a similar fashion to what --quick-* commands already do for other actions (e.g. --quick-add-uid). Context: I'm working on a small scheme that will rely on notations and I'd like to make instructions for people as simple as possible. Thank you in advance! Kind regards, Wiktor -- https://metacode.biz/@wiktor From samir.zulfiquar at gmail.com Fri Jun 7 21:13:04 2019 From: samir.zulfiquar at gmail.com (Samir Zulfiquar) Date: Fri, 7 Jun 2019 15:13:04 -0400 Subject: gnupg installation and verification Message-ID: Hello I just downloaded gnupg and tried to install and verify it. Unfortunately I hardly know how to do anything with a computer other than the basics, so maybe I just didn't interpret the instructions correctly. I downloaded the installer and the open pgp signature to verify it (I have no clue what a pgp signature even is). after I downloaded both I opened the pgp signature file which didn't seem to do much other than bring up text of some sort of code. I then installed gnupg, but I wasn't sure if I verified it correctly. so I decided to try again. I looked at the website again and tried right clicking on the gpg4win-3.1.8 file and went to "moreGpgEX options" and clicked verify. The computer tried to verify it with the pgp signature file but failed. I then went to the wiki page on integrity checks. Most of the things there were too technical for me to understand. the only thing I was able to do is check the file length, which was exactly what it was supposed to be. It dose not seem like there were any download problems, but I highly doubt it could be an attacker like the website said (I downloaded both of the files from gnupg's own website and not some other place) Anyway could someone explain in Leyman's terms what to do? Sorry if the question sounds stupid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From codeguro at gmail.com Sat Jun 8 00:28:51 2019 From: codeguro at gmail.com (Tony Lane) Date: Fri, 7 Jun 2019 18:28:51 -0400 Subject: gnupg installation and verification In-Reply-To: References: Message-ID: <80f7d7a7-fe4f-9a4c-385c-0c0579178f0a@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 GPG is an implementation of the OpenPGP standard. It's software that can help you utilize the tools of public key cryptography. Public key cryptography comes in two flavors: encryption and signatures. The PGP signatures you saw is a special hash that aids in verifying the authenticity of some data. You do this by trusting the public key of some distributor(s) or persons. The signature scheme then allows you to ensure the authenticity of the contents even if it goes through some insecure medium. You can be sure that if the signature is valid that it has been signed by the private key corresponding to the public key you trusted and that it has not been tampered with. The principle being that some change in the data requires a distinct signature, a signature that can be generated by only the holder of the private key. Likewise, public key encryption allows you to communicate securely over an insecure medium. As I said before, this is done with public key cryptography, and the key principle here being that the keys for encryption and keys for decryption are distinct. Deriving the one key from the other is very infeasible. The keys used to encrypt the payload are public and can be exchanged freely, hence the name public keys. The keys used to decrypt the payload are kept secure and known only to the person who generated the keypair, hence the name private keys. Using this scheme you can establish a secure channel and communicate securely without meeting up in person and agreeing on a shared secret. This, paired with signatures, allows you to not only communicate some secret, but also ensure that this secret hasn't been tampered with. You can read the tutorial for GPG here. https://futureboy.us/pgp.html For more details, you can see the GPG manual here: https://www.gnupg.org/documentation/manuals.html On 6/7/19 3:13 PM, Samir Zulfiquar wrote: > Hello I just downloaded gnupg and tried to install and verify it. Unfortunately I hardly know how to do anything with a computer other than the basics, so maybe I just didn't interpret the instructions correctly. I downloaded the installer and the open pgp signature to verify it (I have no clue what a pgp signature even is). after I downloaded both I opened the pgp signature file which didn't seem to do much other than bring up text of some sort of code. I then installed gnupg, but I wasn't sure if I verified it correctly. so I decided to try again. I looked at the website again and tried right clicking on the gpg4win-3.1.8 file and went to "moreGpgEX options" and clicked verify. The computer tried to verify it with the pgp signature file but failed. I then went to the wiki page on integrity checks. Most of the things there were too technical for me to understand. the only thing I was able to do is check the file length, which was exactly what it was supposed to be. It dose > not seem like there were any download problems, but I highly doubt it could be an attacker like the website said (I downloaded both of the files from gnupg's own website and not some other place) Anyway could someone explain in Leyman's terms what to do? Sorry if the question sounds stupid. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -----BEGIN PGP SIGNATURE----- iLgEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXPrlIwAKCRDo8fj9gx4T 0zNbAgjCE1lKuc1nPWrGNwg5LgIRSgXrKs5blMekU99GrpfHzEnk7qtOwYmtPmqd d9Nt9IlEqKos3XdHJGPi8pSYvhPwWgIJAbouNtKbB6Ljb6s5kwD8usgI0gpj7j6u C0P49xJ/qxge3M4VgAKSlI2aQy4lcgJ/FdaCmY45h8+oKJXHRN4TLDrf =D4bp -----END PGP SIGNATURE----- From hassan.mostafa87 at gmail.com Sat Jun 8 01:29:48 2019 From: hassan.mostafa87 at gmail.com (Hassan Mostafa) Date: Sat, 8 Jun 2019 01:29:48 +0200 Subject: Elliptic curve operations Message-ID: dears, It's my first time to use this library and I am not a developer. all what I am doing is elliptic curve operations to simulate some EC based algorithms. first of all I wrote the following code to generate a curve and just get the secret key and display it. it gives me segmentation fault 11. please I need an urgent help in this. # include # include # include # include # include # define AM_PATH_LIBGCRYPT /* # define AM_CPPFLAGS = $(LIBGCRYPT_CFLAGS) # define LDADD = $(LIBGCRYPT_LIBS) */ int main () { /* Version check */ if (gcry_check_version(GCRYPT_VERSION)) puts ("\nIntialization Succeed\n"); else { puts ("libgcrypt version mismatch\n"); exit(2); } /* Disable secure memory */ gcry_control(GCRYCTL_DISABLE_SECMEM,0); /* inform the libgcrypt that the intialization has completed */ gcry_control(GCRYCTL_INITIALIZATION_FINISHED,0); if (!gcry_control(GCRYCTL_INITIALIZATION_FINISHED_P)) { puts ("libgcrypt has not been intialized\n"); abort (); } /* Allocating new context for EC operations */ gcry_ctx_t my_ctx; const char *curve = "NIST P-521" ; gcry_error_t err = 1 ; err = gcry_mpi_ec_new ( &my_ctx, NULL, curve); // Displaying the error puts("Allocating a context for EC operations is"); fputs (gcry_strerror(err), stderr); puts ("\n"); // get the private key const char *d = "d-mpi"; int copy1 = 1; unsigned int x_bits = 0; gcry_mpi_t x = gcry_mpi_new (x_bits); x = gcry_mpi_ec_get_mpi(d, my_ctx, copy1); //displaying the private key gcry_buffer_t x_buffer; x_buffer.size = 0; x_buffer.len = 1024; unsigned char *x_buffer_name = x_buffer.data; size_t x_buffer_len = 1024 ; size_t *x_size; //unsigned int x_copy_bits = 512; //gcry_mpi_t x_copy = gcry_mpi_new (x_copy_bits); //const gcry_mpi_t x_copy = x; //gcry_mpi_release (x_copy); gcry_error_t err2 = 0; err2 = gcry_mpi_print(GCRYMPI_FMT_USG, x_buffer_name, x_buffer_len, x_size, x); fputs (gcry_strerror(err2), stderr); puts ("\n"); //gcry_mpi_release (x_copy); gcry_ctx_release (my_ctx); gcry_mpi_release (x); return 0; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From sac at 300baud.de Sat Jun 8 10:25:47 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 8 Jun 2019 10:25:47 +0200 Subject: ProtonMail and Anonymity In-Reply-To: <9700B423-7461-4DA7-963F-A4CE659BB25F@cwrichardson.com> References: <20190505121014.06cab2fe@pitti.ddsn.net> <93fb66be-7e4a-9c17-a3c4-ee370656f240@gmail.com> <20190505193602.41827424.sac@300baud.de> <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org> <20190506161546.0e40e685.sac@300baud.de> <8AA55BBC-C65F-4C8B-B855-2897412F909B@cwrichardson.com> <20190509163431.44187e02.sac@300baud.de> <9700B423-7461-4DA7-963F-A4CE659BB25F@cwrichardson.com> Message-ID: Christopher W. Richardson wrote: > > > > On 9 May 2019, at 22:34, Stefan Claas wrote: > > > > Am Wed, 8 May 2019 22:08:22 +0200 > > schrieb Christopher W. Richardson : > > > >>> On 6 May 2019, at 16:15, Stefan Claas >>> > wrote: > >>> > >>> ProtonMail's procedure is not anonymous like > >>> real anonymous email services > >> > >> What are some such ?real? anonymous email services? > > > > Sceptic, eh? :-) > > > > However, as soon as time permits I will create a little > > .pdf dokument showing the required and reliable resources > > > > In order to obtain this document you or anybody else > > will have to follow some guidelines, which I will > > outline here, once the document is available. > > I shall patiently await :) Sorry for the late reply, I am still busy with some projects. Anyways, I decided to post now some keywords, which you or anybody else can Google up. OmniMix, QuickSilver Lite, YAMN (check github), Mixmaster4096 (check github), Bitmessage, ZeroNet and for anonymous file transfer Onionshare. Those tools can be all used with Tor. There are probably many more tools available to communicate anonymously, but those are reliable ones used in anonymous circles. Regards Stefan From mirimir at riseup.net Sun Jun 9 04:10:56 2019 From: mirimir at riseup.net (Mirimir) Date: Sat, 8 Jun 2019 19:10:56 -0700 Subject: ProtonMail and Anonymity In-Reply-To: <9700B423-7461-4DA7-963F-A4CE659BB25F@cwrichardson.com> References: <20190505121014.06cab2fe@pitti.ddsn.net> <93fb66be-7e4a-9c17-a3c4-ee370656f240@gmail.com> <20190505193602.41827424.sac@300baud.de> <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org> <20190506161546.0e40e685.sac@300baud.de> <8AA55BBC-C65F-4C8B-B855-2897412F909B@cwrichardson.com> <20190509163431.44187e02.sac@300baud.de> <9700B423-7461-4DA7-963F-A4CE659BB25F@cwrichardson.com> Message-ID: <694ca1b0-4b63-8ef4-ae35-2b3a1a8a9908@riseup.net> On 06/08/2019 01:25 AM, Stefan Claas wrote: > Christopher W. Richardson wrote: > >> >> >>> On 9 May 2019, at 22:34, Stefan Claas wrote: >>> >>> Am Wed, 8 May 2019 22:08:22 +0200 >>> schrieb Christopher W. Richardson : >>> >>>>> On 6 May 2019, at 16:15, Stefan Claas >>>> > wrote: >>>>> >>>>> ProtonMail's procedure is not anonymous like >>>>> real anonymous email services >>>> >>>> What are some such ?real? anonymous email services? >>> >>> Sceptic, eh? :-) >>> >>> However, as soon as time permits I will create a little >>> .pdf dokument showing the required and reliable resources >>> >>> In order to obtain this document you or anybody else >>> will have to follow some guidelines, which I will >>> outline here, once the document is available. >> >> I shall patiently await :) Yeah, I'd also like to see that :) > Sorry for the late reply, I am still busy with some projects. > > Anyways, I decided to post now some keywords, which you or > anybody else can Google up. > > OmniMix, QuickSilver Lite, YAMN (check github), Mixmaster4096 > (check github), Bitmessage, ZeroNet and for anonymous file > transfer Onionshare. Those tools can be all used with Tor. Some years ago, I got Quicksilver Lite working in Debian with Wine. But even then, it hadn't been updated for years. And now I find that https://www.quicksilvermail.net isn't loading. Are people still using nymservers with mixmaster? And do you have working onion URLs for nymservers and news servers? > There are probably many more tools available to communicate > anonymously, but those are reliable ones used in anonymous > circles. > > Regards > Stefan > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From sac at 300baud.de Sun Jun 9 10:20:38 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 9 Jun 2019 10:20:38 +0200 Subject: ProtonMail and Anonymity In-Reply-To: <694ca1b0-4b63-8ef4-ae35-2b3a1a8a9908@riseup.net> References: <20190505121014.06cab2fe@pitti.ddsn.net> <93fb66be-7e4a-9c17-a3c4-ee370656f240@gmail.com> <20190505193602.41827424.sac@300baud.de> <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org> <20190506161546.0e40e685.sac@300baud.de> <8AA55BBC-C65F-4C8B-B855-2897412F909B@cwrichardson.com> <20190509163431.44187e02.sac@300baud.de> <9700B423-7461-4DA7-963F-A4CE659BB25F@cwrichardson.com> <694ca1b0-4b63-8ef4-ae35-2b3a1a8a9908@riseup.net> Message-ID: Mirimir wrote: > Some years ago, I got Quicksilver Lite working in Debian with Wine. > But even then, it hadn't been updated for years. And now I find that > https://www.quicksilvermail.net isn't loading. Are people still using > nymservers with mixmaster? And do you have working onion URLs for > nymservers and news servers? I visited the Quicksilver site a couple of days ago and it was working. I may ping Richard to let him know that it is not working. Regarding Nymservers, you communicate not directly with them, so no .onion needed. What you need to do is set up Mixmaster with Tor, socat and stunnel and then send the config Nym message to the registration email address. There are hover .onion relays available for Mixmaster Remailers, but I do not have them because I use YAMN nowadays. With News Servers I used them in the past also with Tor, socat and stunnel. I may ask a friend if he has .onion addresses for them. I currently don't need them because I have no more a nym to pull messages from a.a.m.. And yes, people still using Mixmaster (and now YAMN) with Usenet or email. :-) Regards Stefan From kirillp at paranoid.email Sun Jun 9 08:57:25 2019 From: kirillp at paranoid.email (Kirill Peskov) Date: Sun, 9 Jun 2019 08:57:25 +0200 Subject: ProtonMail and Anonymity In-Reply-To: <20190505121014.06cab2fe@pitti.ddsn.net> References: <20190505121014.06cab2fe@pitti.ddsn.net> Message-ID: <3a259f3f-2170-1087-2104-84670bed3b6c@paranoid.email> First of all... On 05.05.19 12:12, Stefan Claas wrote: > Hi all, > > appologies for posting this, but I think it could > be of interest for GnuPG users, because ProtoMail > uses the OpenPGP protocol too. It uses OpenPGP protocol, but quite a twisted way. And they're not OpenPGP-compliant, because they're not able to encrypt mails leaving their domain. Any webmail by itself cannot be secure, because provider can always send you 'modified' browser applet and steal your private key and some day ? the passphrase. Real anonymous email services are out there in .onion domain, but they're neither stable nor trusted by non-onion recipients... Cheers, Kirill From wiktor at metacode.biz Sun Jun 9 11:09:28 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Sun, 9 Jun 2019 11:09:28 +0200 Subject: ProtonMail and Anonymity In-Reply-To: <3a259f3f-2170-1087-2104-84670bed3b6c@paranoid.email> References: <20190505121014.06cab2fe@pitti.ddsn.net> <3a259f3f-2170-1087-2104-84670bed3b6c@paranoid.email> Message-ID: Hi Kirill, On 09.06.2019 08:57, Kirill Peskov wrote: > It uses OpenPGP protocol, but quite a twisted way. And they're not > OpenPGP-compliant, because they're not able to encrypt mails leaving > their domain. What do you mean by that? There is an option to add OpenPGP key of a "foreign" contact and send to other e-mail providers just like any oter OpenPGP mail. From what I've seen on OpenPGP mailing list they're also planning to have Web Key Directory key discovery so that I'll be easier to encrypt to people outside ProtonMail > Any webmail by itself cannot be secure, because provider > can always send you 'modified' browser applet and steal your private key > and some day ? the passphrase. Yes, that's a problem. Still, who would discover a compromised Enigmail plugin (that autoupdates too), or even GnuPG? As the code is quite complex and in some cases there are many intermediaries (distro maintainers) it's not quite obvious what code are you running exactly. As for webpages there is also this interesting plugin: https://stosb.com/blog/signed-web-pages/ Kind regards, Wiktor -- https://metacode.biz/@wiktor From sac at 300baud.de Sun Jun 9 11:15:36 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 9 Jun 2019 11:15:36 +0200 Subject: ProtonMail and Anonymity In-Reply-To: <3a259f3f-2170-1087-2104-84670bed3b6c@paranoid.email> References: <20190505121014.06cab2fe@pitti.ddsn.net> <3a259f3f-2170-1087-2104-84670bed3b6c@paranoid.email> Message-ID: Kirill Peskov wrote: > First of all... > > On 05.05.19 12:12, Stefan Claas wrote: > > Hi all, > > > > appologies for posting this, but I think it could > > be of interest for GnuPG users, because ProtoMail > > uses the OpenPGP protocol too. > > It uses OpenPGP protocol, but quite a twisted way. And they're not > OpenPGP-compliant, because they're not able to encrypt mails leaving > their domain. Any webmail by itself cannot be secure, because provider > can always send you 'modified' browser applet and steal your private > key and some day ? the passphrase. > > Real anonymous email services are out there in .onion domain, but > they're neither stable nor trusted by non-onion recipients... Correct and also .onion domains come and go. The only IMHO reliable anonymous email services are if you use Anonymous Remailers (with a Nym account) or Bitmessage (with an additional Mailchuck email gateway address). Regards Stefan From sac at 300baud.de Sun Jun 9 14:13:57 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 9 Jun 2019 14:13:57 +0200 Subject: ProtonMail and Anonymity In-Reply-To: <694ca1b0-4b63-8ef4-ae35-2b3a1a8a9908@riseup.net> References: <20190505121014.06cab2fe@pitti.ddsn.net> <93fb66be-7e4a-9c17-a3c4-ee370656f240@gmail.com> <20190505193602.41827424.sac@300baud.de> <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org> <20190506161546.0e40e685.sac@300baud.de> <8AA55BBC-C65F-4C8B-B855-2897412F909B@cwrichardson.com> <20190509163431.44187e02.sac@300baud.de> <9700B423-7461-4DA7-963F-A4CE659BB25F@cwrichardson.com> <694ca1b0-4b63-8ef4-ae35-2b3a1a8a9908@riseup.net> Message-ID: Mirimir wrote: > And do you have working onion URLs for > nymservers and news servers? Here we go, it is from a.p.a-s: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here are the free Onion SMTP Servers that I am aware of that are working as of April 29, 2019 gbhpq7eihle4btsn.onion:25 sopoccfrkrpuiin5.onion:2525 nyt7rlpjogd24qx7.onion:587(TLS) nyt7rlpjogd24qx7.onion:25 nyt7rlpjogd24qx7.onion:2525 nyt7rlpjogd24qx7.onion:465 bshc44ac76q3kskw.onion:25 oc6bguylwowxvs62.onion:2525 Frell must be the first remailer in your remailer chain when using bshc44ac76q3kskw.onion. Here are the free Onion NNTP Servers that I am aware of that are working as of April 29, 2019 ruxuklsvo4pk74m5.onion:119 neodomea5yrhcabc.onion:119 asq5mo52aghemn2i.onion:119 I will try to update this on a weekly basis going forward and if there are others that are working please update this thread. -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlzHSkgACgkQrrtSX34nv6ZyFgCg44BedGUs4jzYz204e6GlKp/9 E/cAoNa6V2YQzz9Tkb6CyyM0BOl/IRK9 =2Cfr -----END PGP SIGNATURE----- Regards Stefan From ml at mareichelt.com Sun Jun 9 14:16:08 2019 From: ml at mareichelt.com (Markus Reichelt) Date: Sun, 9 Jun 2019 14:16:08 +0200 Subject: Adding notations with quick commands In-Reply-To: References: Message-ID: <20190609121608.GA5982@pc21.mareichelt.com> * Wiktor Kwapisiewicz via Gnupg-users wrote: > in a similar fashion to what --quick-* commands already do for other actions > (e.g. --quick-add-uid). --set-notation maybe? HTH -- left blank, right bald From mirimir at riseup.net Sun Jun 9 19:07:24 2019 From: mirimir at riseup.net (Mirimir) Date: Sun, 9 Jun 2019 10:07:24 -0700 Subject: ProtonMail and Anonymity In-Reply-To: <694ca1b0-4b63-8ef4-ae35-2b3a1a8a9908@riseup.net> References: <20190505121014.06cab2fe@pitti.ddsn.net> <93fb66be-7e4a-9c17-a3c4-ee370656f240@gmail.com> <20190505193602.41827424.sac@300baud.de> <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org> <20190506161546.0e40e685.sac@300baud.de> <8AA55BBC-C65F-4C8B-B855-2897412F909B@cwrichardson.com> <20190509163431.44187e02.sac@300baud.de> <9700B423-7461-4DA7-963F-A4CE659BB25F@cwrichardson.com> <694ca1b0-4b63-8ef4-ae35-2b3a1a8a9908@riseup.net> Message-ID: <84c5b999-c70b-2301-1aab-dd4e175eab53@riseup.net> On 06/09/2019 01:20 AM, Stefan Claas wrote: > Mirimir wrote: > >> Some years ago, I got Quicksilver Lite working in Debian with Wine. >> But even then, it hadn't been updated for years. And now I find that >> https://www.quicksilvermail.net isn't loading. Are people still using >> nymservers with mixmaster? And do you have working onion URLs for >> nymservers and news servers? > > I visited the Quicksilver site a couple of days ago and it was working. > > I may ping Richard to let him know that it is not working. Thanks. Any chance of a native Linux port of Quicksilver? I asked, some years ago, and got that it wasn't feasible. > Regarding Nymservers, you communicate not directly with them, so > no .onion needed. What you need to do is set up Mixmaster with > Tor, socat and stunnel and then send the config Nym message to > the registration email address. There are hover .onion relays > available for Mixmaster Remailers, but I do not have them because > I use YAMN nowadays. > > With News Servers I used them in the past also with Tor, socat and > stunnel. I may ask a friend if he has .onion addresses for them. > I currently don't need them because I have no more a nym to pull > messages from a.a.m.. And yes, people still using Mixmaster (and now > YAMN) with Usenet or email. :-) > > Regards > Stefan > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From wiktor at metacode.biz Sun Jun 9 19:17:10 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Sun, 9 Jun 2019 19:17:10 +0200 Subject: Adding notations with quick commands In-Reply-To: <20190609121608.GA5982@pc21.mareichelt.com> References: <20190609121608.GA5982@pc21.mareichelt.com> Message-ID: <45c17b27-132b-aafe-e89e-e5c8c51903f6@metacode.biz> Hi Markus, On 09.06.2019 14:16, Markus Reichelt wrote: >> in a similar fashion to what --quick-* commands already do for other actions >> (e.g. --quick-add-uid). > > --set-notation maybe? Yes, but as far as I understand --set-notation is only a modifier that needs to be used with another command (e.g. --quick-sign-key). I tried using it with my own fingerprint twice but it didn't succeed: $ gpg -u F470E50DCB1AD5F1E64E08644A63613A4D6E4094 --set-notation test at example.com=zzzz --quick-sign-key F470E50DCB1AD5F1E64E08644A63613A4D6E4094 "Test McTestington " was already signed by key 4A63613A4D6E4094 Nothing to sign with key 4A63613A4D6E4094 gpg: Key not changed so no update needed. Kind regards, Wiktor -- https://metacode.biz/@wiktor From sac at 300baud.de Sun Jun 9 19:44:32 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 9 Jun 2019 19:44:32 +0200 Subject: ProtonMail and Anonymity In-Reply-To: <84c5b999-c70b-2301-1aab-dd4e175eab53@riseup.net> References: <20190505121014.06cab2fe@pitti.ddsn.net> <93fb66be-7e4a-9c17-a3c4-ee370656f240@gmail.com> <20190505193602.41827424.sac@300baud.de> <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org> <20190506161546.0e40e685.sac@300baud.de> <8AA55BBC-C65F-4C8B-B855-2897412F909B@cwrichardson.com> <20190509163431.44187e02.sac@300baud.de> <9700B423-7461-4DA7-963F-A4CE659BB25F@cwrichardson.com> <694ca1b0-4b63-8ef4-ae35-2b3a1a8a9908@riseup.net> <84c5b999-c70b-2301-1aab-dd4e175eab53@riseup.net> Message-ID: Mirimir wrote: > Thanks. Any chance of a native Linux port of Quicksilver? I asked, > some years ago, and got that it wasn't feasible. You're welcome! What I would do under Linux, wishing to run Mixmaster (latest Version with 4k keys support) and using a Nym: Check the docs here, they are for Remailers, but should help you to compile Mixmaster under Debian. https://inwtx.net/remailer.html Mixmaster has also a nice ncurses Interface. Then to handroll a Nym account with GnuPG: http://mixnym.net/ And finally to fetch messages from a.a.m.: https://github.com/crooks/aam2mail If you need help with setting up Tor, socat and stunnel let me know. Hope this helps! Regards Stefan From sac at 300baud.de Sun Jun 9 19:51:14 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 9 Jun 2019 19:51:14 +0200 Subject: ProtonMail and Anonymity References: <20190505121014.06cab2fe@pitti.ddsn.net> <93fb66be-7e4a-9c17-a3c4-ee370656f240@gmail.com> <20190505193602.41827424.sac@300baud.de> <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org> <20190506161546.0e40e685.sac@300baud.de> <8AA55BBC-C65F-4C8B-B855-2897412F909B@cwrichardson.com> <20190509163431.44187e02.sac@300baud.de> <9700B423-7461-4DA7-963F-A4CE659BB25F@cwrichardson.com> <694ca1b0-4b63-8ef4-ae35-2b3a1a8a9908@riseup.net> <84c5b999-c70b-2301-1aab-dd4e175eab53@riseup.net> Message-ID: Stefan Claas wrote: > Hope this helps! And you probably want an up to date allpingers.txt: # A L L P I N G E R S' I N D E X # # Updated: 09 June 2019 # This list was last updated by SEC3 # Please email corrections to: pinger-admin at sec3.net [apricot] base = https://apricot.fruiti.org/echolot/ rlist = https://apricot.fruiti.org/echolot/rlist.txt mlist = https://apricot.fruiti.org/echolot/mlist.txt rlist2 = https://apricot.fruiti.org/echolot/rlist2.txt mlist2 = https://apricot.fruiti.org/echolot/mlist2.txt rlist_html = https://apricot.fruiti.org/echolot/rlist.html mlist_html = https://apricot.fruiti.org/echolot/mlist.html rlist2_html = https://apricot.fruiti.org/echolot/rlist2.html mlist2_html = https://apricot.fruiti.org/echolot/mlist2.html pgpring = https://apricot.fruiti.org/echolot/pgp-all.asc pgpring_rsa = https://apricot.fruiti.org/echolot/pgp-rsa.asc mixring = https://apricot.fruiti.org/echolot/pubring.mix type2list = https://apricot.fruiti.org/echolot/type2.list [austria] base = https://www.tahina.priv.at/~cm/stats/ rlist = https://www.tahina.priv.at/~cm/stats/rlist.txt mlist = https://www.tahina.priv.at/~cm/stats/mlist.txt rlist2 = https://www.tahina.priv.at/~cm/stats/rlist2.txt mlist2 = https://www.tahina.priv.at/~cm/stats/mlist2.txt rlist_html = https://www.tahina.priv.at/~cm/stats/rlist.html mlist_html = https://www.tahina.priv.at/~cm/stats/mlist.html rlist2_html = https://www.tahina.priv.at/~cm/stats/rlist2.html mlist2_html = https://www.tahina.priv.at/~cm/stats/mlist2.html pgpring = https://www.tahina.priv.at/~cm/stats/pgp-all.asc pgpring_rsa = https://www.tahina.priv.at/~cm/stats/pgp-rsa.asc mixring = https://www.tahina.priv.at/~cm/stats/pubring.mix type2list = https://www.tahina.priv.at/~cm/stats/type2.list [deuxpi] base = https://www.deuxpi.ca/echolot/ rlist = https://www.deuxpi.ca/echolot/rlist.txt mlist = https://www.deuxpi.ca/echolot/mlist.txt rlist2 = https://www.deuxpi.ca/echolot/rlist2.txt mlist2 = https://www.deuxpi.ca/echolot/mlist2.txt rlist_html = https://www.deuxpi.ca/echolot/rlist.html mlist_html = https://www.deuxpi.ca/echolot/mlist.html rlist2_html = https://www.deuxpi.ca/echolot/rlist2.html mlist2_html = https://www.deuxpi.ca/echolot/mlist2.html pgpring = https://www.deuxpi.ca/echolot/pgp-all.asc pgpring_rsa = https://www.deuxpi.ca/echolot/pgp-rsa.asc mixring = https://www.deuxpi.ca/echolot/pubring.mix type2list = https://www.deuxpi.ca/echolot/type2.list [eurovibes] base = http://www.eurovibes.org/echolot/ rlist = http://www.eurovibes.org/echolot/rlist.txt mlist = http://www.eurovibes.org/echolot/mlist.txt rlist2 = http://www.eurovibes.org/echolot/rlist2.txt mlist2 = http://www.eurovibes.org/echolot/mlist2.txt rlist_html = http://www.eurovibes.org/echolot/rlist.html mlist_html = http://www.eurovibes.org/echolot/mlist.html rlist2_html = http://www.eurovibes.org/echolot/rlist2.html mlist2_html = http://www.eurovibes.org/echolot/mlist2.html pgpring = http://www.eurovibes.org/echolot/pgp-all.asc pgpring_rsa = http://www.eurovibes.org/echolot/pgp-rsa.asc mixring = http://www.eurovibes.org/echolot/pubring.mix type2list = http://www.eurovibes.org/echolot/type2.list [frell] base = https://echolot.theremailer.net/ rlist = https://echolot.theremailer.net/rlist.txt mlist = https://echolot.theremailer.net/mlist.txt rlist2 = https://echolot.theremailer.net/rlist2.txt mlist2 = https://echolot.theremailer.net/mlist2.txt rlist_html = https://echolot.theremailer.net/rlist.html mlist_html = https://echolot.theremailer.net/mlist.html rlist2_html = https://echolot.theremailer.net/rlist2.html mlist2_html = https://echolot.theremailer.net/mlist2.html pgpring = https://echolot.theremailer.net/pgp-all.asc pgpring_rsa = https://echolot.theremailer.net/pgp-rsa.asc mixring = https://echolot.theremailer.net/pubring.mix type2list = https://echolot.theremailer.net/type2.list [kroken] base = https://rlist.uni-boeblingen.de/ rlist = https://rlist.uni-boeblingen.de/rlist.txt mlist = https://rlist.uni-boeblingen.de/mlist.txt rlist2 = https://rlist.uni-boeblingen.de/rlist2.txt mlist2 = https://rlist.uni-boeblingen.de/mlist2.txt rlist_html = https://rlist.uni-boeblingen.de/rlist.html mlist_html = https://rlist.uni-boeblingen.de/mlist.html rlist2_html = https://rlist.uni-boeblingen.de/rlist2.html mlist2_html = https://rlist.uni-boeblingen.de/mlist2.html pgpring = https://rlist.uni-boeblingen.de/pgp-all.asc pgpring_rsa = https://rlist.uni-boeblingen.de/pgp-rsa.asc mixring = https://rlist.uni-boeblingen.de/pubring.mix type2list = https://rlist.uni-boeblingen.de/type2.list [mixmin] base = https://www.mixmin.net/echolot/ rlist = https://www.mixmin.net/echolot/rlist.txt mlist = https://www.mixmin.net/echolot/mlist.txt rlist2 = https://www.mixmin.net/echolot/rlist2.txt mlist2 = https://www.mixmin.net/echolot/mlist2.txt rlist_html = https://www.mixmin.net/echolot/rlist.html mlist_html = https://www.mixmin.net/echolot/mlist.html rlist2_html = https://www.mixmin.net/echolot/rlist2.html mlist2_html = https://www.mixmin.net/echolot/mlist2.html pgpring = https://www.mixmin.net/echolot/pgp-all.asc pgpring_rsa = https://www.mixmin.net/echolot/pgp-rsa.asc mixring = https://www.mixmin.net/echolot/pubring.mix type2list = https://www.mixmin.net/echolot/type2.list [paranoia] base = https://remailer.paranoici.org/stats/echolot.html rlist = https://remailer.paranoici.org/stats/rlist.txt mlist = https://remailer.paranoici.org/stats/mlist.txt rlist2 = https://remailer.paranoici.org/stats/rlist2.txt mlist2 = https://remailer.paranoici.org/stats/mlist2.txt rlist_html = https://remailer.paranoici.org/stats/rlist.html mlist_html = https://remailer.paranoici.org/stats/mlist.html rlist2_html = https://remailer.paranoici.org/stats/rlist2.html mlist2_html = https://remailer.paranoici.org/stats/mlist2.html pgpring = https://remailer.paranoici.org/stats/pgp-all.asc pgpring_rsa = https://remailer.paranoici.org/stats/pgp-rsa.asc mixring = https://remailer.paranoici.org/stats/pubring.mix type2list = https://remailer.paranoici.org/stats/type2.list [sec3] base = https://sec3.net/echolot/ rlist = https://sec3.net/echolot/rlist.txt mlist = https://sec3.net/echolot/mlist.txt rlist2 = https://sec3.net/echolot/rlist2.txt mlist2 = https://sec3.net/echolot/mlist2.txt rlist_html = https://sec3.net/echolot/rlist.html mlist_html = https://sec3.net/echolot/mlist.html rlist2_html = https://sec3.net/echolot/rlist2.html mlist2_html = https://sec3.net/echolot/mlist2.html pgpring = https://sec3.net/echolot/pgp-all.asc pgpring_rsa = https://sec3.net/echolot/pgp-rsa.asc mixring = https://sec3.net/echolot/pubring.mix type2list = https://sec3.net/echolot/type2.list [senshi] base = http://senshiweb.webhop.net rlist2 = http://senshiweb.webhop.net/rlist2.txt rlist_html = http://senshiweb.webhop.net/rlist.html mlist2 = http://senshiweb.webhop.net/mlist2.txt mlist_html = http://senshiweb.webhop.net/mlist.html mixring = http://senshiweb.webhop.net/pubring.mix type2list = http://senshiweb.webhop.net/type2.list Regards Stefan From johndoe65534 at mail.com Sun Jun 9 20:04:52 2019 From: johndoe65534 at mail.com (john doe) Date: Sun, 9 Jun 2019 20:04:52 +0200 Subject: gnupg installation and verification In-Reply-To: References: Message-ID: <7056cf19-b0d0-6b21-29c8-3a32ee789a62@mail.com> On 6/7/2019 9:13 PM, Samir Zulfiquar wrote: > Hello I just downloaded gnupg and tried to install and verify it. > Unfortunately I hardly know how to do anything with a computer other than > the basics, so maybe I just didn't interpret the instructions correctly. I > downloaded the installer and the open pgp signature to verify it (I have no > clue what a pgp signature even is). after I downloaded both I opened the > pgp signature file which didn't seem to do much other than bring up text of > some sort of code. I then installed gnupg, but I wasn't sure if I verified > it correctly. so I decided to try again. I looked at the website again and > tried right clicking on the gpg4win-3.1.8 file and went to "moreGpgEX > options" and clicked verify. The computer tried to verify it with the pgp > signature file but failed. I then went to the wiki page on integrity > checks. Most of the things there were too technical for me to understand. > the only thing I was able to do is check the file length, which was exactly > what it was supposed to be. It dose not seem like there were any download > problems, but I highly doubt it could be an attacker like the website said > (I downloaded both of the files from gnupg's own website and not some other > place) Anyway could someone explain in Leyman's terms what to do? Sorry if > the question sounds stupid. > > If you don't have access to an other instance of gpg, you don't have any other choise then to first install gpg4win and 'verify' if the downloaded executable has not been tempered with. That is, what you have already done. You should familiorize your self with 'checksum' 'gpg signature verification', the below URL is a start: https://security.stackexchange.com/questions/189000/how-to-verify-the-checksum-of-a-downloaded-file-pgp-sha-etc -- John Doe From dkg at fifthhorseman.net Mon Jun 10 00:18:34 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 09 Jun 2019 18:18:34 -0400 Subject: how to integrate ca-certificates with gpgsm (for email s/mime signature verification) In-Reply-To: <87ef48t0ta.fsf@len.workgroup> References: <87ef48t0ta.fsf@len.workgroup> Message-ID: <875zpepflx.fsf@fifthhorseman.net> Hi Gregor, everyone-- On Wed 2019-06-05 19:10:57 +0200, Gregor Zattler wrote: > I use notmuch-emacs to read my email and sometimes do use GnuPG, > therefore notmuch-emacs is configured to verify signatures but > does so also for S/MIME signatures. When displaying such emails > I'm asked if I trust the respective Root CAs Cert. That's tedious. I agree that this is not only tedious -- it's an impossible question for users to answer, especially if the signature verification is done at indexing time, when the user doesn't even have a smidgen of context. See also https://bugs.debian.org/888025 for a mutt+gpgsm example of this kind of frustration. (i'm cc'ing that bug report since it has seen no decisive action; perhaps this discussion will help move things along there) The current behavior is: The user sees "do you ultimately trust XXX to correctly certify user certificates?", with "cancel" and "yes". If they answer "yes", they're asked "please verify that the certificate identified as XXX has the fingerprint YYYY", with "cancel", and "correct" i can't imagine any situation where a user is equipped to answer the first question -- even if they believe that it's being asked in good faith. and the second question is somehow even more impossible. What certificate? How is the user supposed to know what to verify here? > Therefore I would like to integrate certificates provided by > debians ca-certificates package with gpgsm, but the only way I > found to do so, would be to manually import all those > certificates. I'm one of the debian maintainers for gnupg, and i admit that i haven't put a lot of work into the gpgsm system integration. I did a bit of digging just now, and i've got some ideas, but be warned that i haven't dug deeply into the tradeoffs here yet. i welcome feedback! looking at the documentation for trustlist.txt in gpg-agent(1) (it seems odd to have it documented there, since i thought gpg-agent was for secret key material only, weird!), it looks like trustlist.txt has an `include-default` option, which maybe defaults to `/etc/gnupg/trustlist.txt` on debian (i haven't done much testing!) Of course, gpgsm has to learn about these root certificates somehow as well, and i think doesn't have an easy way to make use of a separate keybox (perhaps Werner or another GnuPG dev can correct me on this). Read gpgsm(1), i see that /usr/share/gnupg/com-certs.pem could be set up as a symlink to /etc/ssl/certs/ca-certificates.crt. But this only works to import those root certificates at the initial creation of pubring.kbx, so it won't work in an ongoing way (e.g. when ca-certificates gets updated, they won't be updated. So, what can Debian do to improve this integration? here is a series of suggestions of changes to the gnupg2 source package in debian (i have no code to back them up yet, commentary and patches welcome): * make sure gpgsm Recommends: ca-certificates * add /etc/ca-certificates/update.d/gnupg to the gpgsm package (see update-ca-certificates(8) for a description of this hook), which should maintain /var/lib/gnupg/trustlist.txt and /var/lib/gnupg/ca-certificates.kbx . (Maybe add a postinst script to invoke this as well?) * consider adding a symlink (a conffile, yuck): - /etc/gnupg/trustlist.txt ? /var/lib/gnupg/trustlist.txt * add a symlink to the gpgsm package: - /usr/share/gnupg/com-certs.pem ? /etc/ssl/certs/ca-certificates.crt * (maybe) change the default of gpg-agent's allow-mark-trusted to be false, rather than true. This is both a safety precaution, and a usability improvement, since i can't think of a context in which the user is well-prepared to actually answer these questions in the way that they're presented. This is still imperfect (the client has no way to learn of certiifcates added via ca-certificates after they've first populated their pubring.kbx), but it strikes me that it would be a strict improvement over the status quo. What do you think? After doing a brief review, i have a bunch more questions for GnuPG upstream too: * Could i convince you to search for trustlist.txt in /var/lib/gnupg/trustlist.txt as the system default, if /etc/gnupg/trustlist.txt is not found? That is, if no trustlist.txt is present in $GNUPGHOME, or if $GNUPGHOME/trustlist.txt has the include-default directive, it looks first for /etc/gnupg/trustlist.txt. if it is found, it uses it. if it is not found, it looks in /var/lib/gnupg/trustlist.txt. That would relieve me of needing to maintain a conffile in the debian package, which i would strongly prefer. * if i have an auto-generated /var/lib/gnupg/ca-certificates.kbx that is kept in sync with the system trustlist, is there a way that i can coax gpgsm to use it as a secondary (read-only) keyring by default? (i'm not asking for presence in this keyring to be used to infer trust; just that these certificates are always known, and can therefore be referenced (or deliberately ignored or marked untrustworthy) in the user's trustlist.txt. Is such an option available already? the gpgsm(1) manpage doesn't even mention --keyring, but it seems to support --keyring anyway. so maybe there are other options i'm not aware of that could do this already, like some sort of --system-keyring ? * can i convince you to disable "allow-mark-trusted" in gpg-agent by default? What is the use case where this seems like a sensible thing to offer? * can we improve the documentation of trustlist.txt? From the comments auto-written to this file, it looks like it's intended to be part of the GnuPG family's "API" -- users are told how to deal with this file when editing it directly. If that's the case, we really need to know what it is supposed to do, in a concise and easily findable way. gpgsm(1) refers to it, but doesn't direct the user toward any other documentation. The comments written into the file when it is auto-generated are unclear. what does the 'S' and 'P' and '*' flag mean? (in the codebase, i see that they mean "S/MIME" and "PGP" and either, but that's still unclear. what is the fingerprint *of* -- is it the X.509 certificate? if so, what could 'P' possibly mean? Is it the OpenPGP v4 fingerprint? if so, what could 'S' possibly mean? What would this fingerprint mean for '*'? if it's 'P', does that mean it has an effect on gpg and not just gpgsm?) doc/debugging.texi claims: You may use the @code{relax} flag in @file{trustlist.txt} to accept the certificate anyway. Note that the fingerprint and this flag may only be added manually to @file{trustlist.txt}. And yet, when i use: gpg-connect-agent "$DIGEST S whatever" /bye it seems to add the "relax" keyword. The header auto-written into trustlist.txt is not only bulky -- it's prone to falling out of date. If this were better documented, and that documentation were placed someplace stable by the installed package, then when writing out a trustlist.txt, you could just have a one-line header pointing to the documentation. To be clear, my goals here are similar to my goals for gpg: * default user configuration should be as close as possible to no configuration at all * the default system configuration should also be as close to no configuration as possible. * the package should ship with good documentation in a stable, easily-findable place. * the defaults should be well integrated into the host operationg system. * it should be possible for the user to have their user account diverge from the system defaults as narrowly as possible, while still receiving updates to the system defaults during package upgrades that retain their divergences. * it should be possible for the system administrator to have the system defaults diverge as narrowly as possible from the package defaults, without doing a lot of work at package upgrade to retain that divergence. Happy to hear any feedback about these suggestions and questions! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Mon Jun 10 16:52:05 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 10 Jun 2019 16:52:05 +0200 Subject: ProtonMail and Anonymity References: <20190505121014.06cab2fe@pitti.ddsn.net> <93fb66be-7e4a-9c17-a3c4-ee370656f240@gmail.com> <20190505193602.41827424.sac@300baud.de> <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org> <20190506161546.0e40e685.sac@300baud.de> <8AA55BBC-C65F-4C8B-B855-2897412F909B@cwrichardson.com> <20190509163431.44187e02.sac@300baud.de> <9700B423-7461-4DA7-963F-A4CE659BB25F@cwrichardson.com> <694ca1b0-4b63-8ef4-ae35-2b3a1a8a9908@riseup.net> Message-ID: Stefan Claas wrote: > I visited the Quicksilver site a couple of days ago and it was > working. > > I may ping Richard to let him know that it is not working. O.k. his site is up and running, but his LE cert is expired. Regards Stefan From hassan.mostafa87 at gmail.com Wed Jun 12 10:08:01 2019 From: hassan.mostafa87 at gmail.com (Hassan Mostafa) Date: Wed, 12 Jun 2019 10:08:01 +0200 Subject: library intialization error Message-ID: Hi, I am a new to libgcrypt. i had an error when I tried just to initialize the library. I followed the manual for initialization but when try to check it's success it give me general error. the code as following # include # include # include # include # include # define AM_PATH_LIBGCRYPT int main () { /* Version check */ if (!gcry_check_version(GCRYPT_VERSION)) { fputs ("libgcrypt version mismatch\n", stderr); exit(2); } /* intialization success check */ gcry_error_t e1 = gcry_control (GCRYCTL_ANY_INITIALIZATION_P); fputs (gcry_strerror(e1), stderr); puts ("\n"); return 0; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Jun 13 15:30:37 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Jun 2019 15:30:37 +0200 Subject: library intialization error In-Reply-To: (Hassan Mostafa's message of "Wed, 12 Jun 2019 10:08:01 +0200") References: Message-ID: <87sgsdr4si.fsf@wheatstone.g10code.de> Hi! On Wed, 12 Jun 2019 10:08, hassan.mostafa87 at gmail.com said: > # include > > # define AM_PATH_LIBGCRYPT What purpose has this macro? Did you mized something up with a configure macro. Anyway, it is not a problem. > /* intialization success check */ > > gcry_error_t e1 = gcry_control (GCRYCTL_ANY_INITIALIZATION_P); > fputs (gcry_strerror(e1), stderr); > puts ("\n"); Let's check the manual: 'GCRYCTL_ANY_INITIALIZATION_P; Arguments: none' This command returns true if the library has been basically initialized. Such a basic initialization happens implicitly with many commands to get certain internal subsystems running. The common and suggested way to do this basic initialization is by calling gcry_check_version. GPG_ERR_GENERAL is what you see and that is in C considered a True. So the library is successful initialized. You don't need this check, though. Only a few very special applications may need it. Functions which end in "_p" commonly return a boolean value and thus we don't have an error code here. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From s.salih at futurepipe.com Thu Jun 13 09:58:45 2019 From: s.salih at futurepipe.com (Sameera Salih) Date: Thu, 13 Jun 2019 07:58:45 +0000 Subject: GPG automated decryption failing Message-ID: Hello I am using the below command for automated decryption of PGP files (GNUPG4WIN / Kleoptatra). echo mypassphrase|gpg --logger-file "D:\FileShare\PGPScripts\SFTP\gpglog.log" --pinentry-mode loopback --batch --yes --passphrase-fd 0 --decrypt-files "D:\FileShare\Concur\WIP\*.pgp" However after a certain time period 4 hours or so, it throws the below error. How can I resolve this? Is there a setting to set the passphrase to never expire public key decryption failed: Bad passphrase decryption failed: No secret key Kind regards, Sameera Salih Application Analyst - Business Systems Work: +971 4 5124833 Test DISCLAIMER: This message contains confidential, privileged information intended solely for the addressee. Please do not read, copy, or disseminate it unless you are the addressee. If you have received this message in error, please notify the sender immediately by e-mail and delete the message from your system. This e-mail communication is for informational purposes only. No such communication is intended to constitute either an electronic record or an electronic signature, or to constitute any agreement by the sender to conduct a transaction by electronic means. Any such intention or agreement is hereby expressly disclaimed unless otherwise specifically indicated. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Future Pipe Industries Group. The recipient should check this email and any attachments for the presence of viruses. Future Pipe Industries Group accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oscar at spindel.tax Fri Jun 14 10:12:51 2019 From: oscar at spindel.tax (Oscar Carlsson) Date: Fri, 14 Jun 2019 10:12:51 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? Message-ID: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> Hi, I'm generally curious on your opinions on the latest new keyserver, this time running a new software than the normal keyservers. They seem to have a different model which minimize the amount of information available, to be compliant with GDPR and friends. Do you think there are any downsides to this? Regards, Oscar From oscar at spindel.tax Fri Jun 14 10:40:44 2019 From: oscar at spindel.tax (Oscar Carlsson) Date: Fri, 14 Jun 2019 10:40:44 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <87pnng36wq.fsf@iki.fi> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <87pnng36wq.fsf@iki.fi> Message-ID: <688c7f99883b380cf17984b9e4c9b732@spindel.tax> 2019-06-14 10:31 skrev Teemu Likonen: > Oscar Carlsson via Gnupg-users [2019-06-14 10:12:51+02] wrote: > >> I'm generally curious on your opinions on the latest new keyserver, >> this time running a new software than the normal keyservers. >> >> They seem to have a different model which minimize the amount of >> information available, to be compliant with GDPR and friends. Do you >> think there are any downsides to this? > > You should have added a link to information about this "latest new > keyserver" and its "different model" which you are referring to. Well, > here: > > https://keys.openpgp.org/about/news#2019-06-12-launch Ah, sorry about that! And thanks for adding it for me. I had added it to the title and didn't think of adding it to the body as well. Oscar From tlikonen at iki.fi Fri Jun 14 10:31:01 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Fri, 14 Jun 2019 11:31:01 +0300 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> (Oscar Carlsson via Gnupg-users's message of "Fri, 14 Jun 2019 10:12:51 +0200") References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> Message-ID: <87pnng36wq.fsf@iki.fi> Oscar Carlsson via Gnupg-users [2019-06-14 10:12:51+02] wrote: > I'm generally curious on your opinions on the latest new keyserver, > this time running a new software than the normal keyservers. > > They seem to have a different model which minimize the amount of > information available, to be compliant with GDPR and friends. Do you > think there are any downsides to this? You should have added a link to information about this "latest new keyserver" and its "different model" which you are referring to. Well, here: https://keys.openpgp.org/about/news#2019-06-12-launch -- /// Teemu Likonen - .-.. // // PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From wiktor at metacode.biz Fri Jun 14 11:59:16 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Fri, 14 Jun 2019 11:59:16 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> Message-ID: <6e16b117-c492-f698-f150-095e8720fe74@metacode.biz> Hi Oscar, On 14.06.2019 10:12, Oscar Carlsson via Gnupg-users wrote: > I'm generally curious on your opinions on the latest new keyserver, this > time running a new software than the normal keyservers. It's definitely faster and more responsive. That was my personal pain point when interacting with SKS. For example I'm working on a small thing that fetches keys from keyservers. I push my modified key, fetch it from SKS and... nope, no changes are visible (because of nginx caching). Then a different, old set of data is visible. Then timeout. Etc. keys.openpgp.org just works. I push data and it's available. > They seem to have a different model which minimize the amount of > information available, to be compliant with GDPR and friends. Do you > think there are any downsides to this? Storing endless amounts of data without any kind of verification was a bad idea. Maybe SKS was designed in good old times when no-one would try to take advantage of it but in 2019 validating e-mail address is bare minimum a service such as this should do. The current shortcoming is stripping third-party signatures. So Web of Trust wouldn't work (for good reasons described in the FAQ [0]). For some people this may be surprising. [0]: https://keys.openpgp.org/about/faq#third-party-signatures For the record I don't think keys.openpgp.org is in any way revolutionary as it is now. It's a bare minimum keyserver that OpenPGP needed for a long time. Fortunately the team behind it has more ideas that could only improve the overall image and UX of OpenPGP in the wider community. Kind regards, Wiktor -- https://metacode.biz/@wiktor From andrewg at andrewg.com Fri Jun 14 12:04:16 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 14 Jun 2019 11:04:16 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <87pnng36wq.fsf@iki.fi> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <87pnng36wq.fsf@iki.fi> Message-ID: On 14/06/2019 09:31, Teemu Likonen wrote: > Oscar Carlsson via Gnupg-users [2019-06-14 10:12:51+02] wrote: > >> I'm generally curious on your opinions on the latest new keyserver, >> this time running a new software than the normal keyservers. >> >> They seem to have a different model which minimize the amount of >> information available, to be compliant with GDPR and friends. Do you >> think there are any downsides to this? > > You should have added a link to information about this "latest new > keyserver" and its "different model" which you are referring to. Well, > here: > > https://keys.openpgp.org/about/news#2019-06-12-launch I think it's interesting, but it has a few shortcomings. For a start, it only supports email userids - so it is incompatible with monkeysphere. It's also a centralised resource, meaning it's not resilient enough for distributing revocations, which is the main use case for SKS these days (there are already several alternative systems for discovery). So it's not an SKS-killer (yet). -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From dgouttegattat at incenp.org Fri Jun 14 12:56:03 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 14 Jun 2019 11:56:03 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> Message-ID: <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> Hi, On Fri, Jun 14, 2019 at 10:12:51AM +0200, Oscar Carlsson via Gnupg-users wrote: >I'm generally curious on your opinions on the latest new keyserver, >this time running a new software than the normal keyservers. For what it's worth, my main concern is that it is a centralized service. This puts whoever is running keys.openpgp.org in a uniquely good position to do Bad Things?. Of course I don't expect they would, but the point is, they could (or they could be forced to). That being said, I have nothing better to propose and overall I welcome any attempt, however imperfect, to make OpenPGP slightly easier and/or more comfortable to use. (And I do note that Hagrid developers "plan to explore options for a distributed service in the future" [1].) Regards, - Damien [1] https://keys.openpgp.org/about/faq -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From sac at 300baud.de Fri Jun 14 16:02:29 2019 From: sac at 300baud.de (Stefan Claas) Date: Fri, 14 Jun 2019 16:02:29 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> Message-ID: Damien Goutte-Gattat via Gnupg-users wrote: > Hi, > > On Fri, Jun 14, 2019 at 10:12:51AM +0200, Oscar Carlsson via Gnupg-users > wrote: > >I'm generally curious on your opinions on the latest new keyserver, > >this time running a new software than the normal keyservers. > > For what it's worth, my main concern is that it is a centralized > service. > > This puts whoever is running keys.openpgp.org in a uniquely good > position to do Bad Things?. Of course I don't expect they would, but the > point is, they could (or they could be forced to). Interesting to read young peoples thoughts. Can you give a good reason why key servers should be a decentralized distributing medium? For Warez etc, like p2p Networks I can understand this. Why not let key servers be run, like this new one, on behalf of Government Institutions, or commercial Services etc. like S/MIME ldap Servers? Would a dissident or other people really benefit from the old style key server medium? I mean when third parties have them on their radar it would not help them much, right? The only benefit I see is that 3rd parties, not known to us, can do "research" with a key dump, without letting us know. With a centralized approach and run on behalf by proper authorities this would be not possible, and if, they can do this anyways with what we have now. Regards Stefan From mgorny at gentoo.org Fri Jun 14 16:13:35 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Fri, 14 Jun 2019 16:13:35 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> Message-ID: <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> On Fri, 2019-06-14 at 11:56 +0100, Damien Goutte-Gattat via Gnupg-users wrote: > Hi, > > On Fri, Jun 14, 2019 at 10:12:51AM +0200, Oscar Carlsson via Gnupg-users wrote: > > I'm generally curious on your opinions on the latest new keyserver, > > this time running a new software than the normal keyservers. > > For what it's worth, my main concern is that it is a centralized > service. > > This puts whoever is running keys.openpgp.org in a uniquely good > position to do Bad Things?. Of course I don't expect they would, but the > point is, they could (or they could be forced to). To be honest, I've been considering similar problems with SKS lately and I don't really think a distributed service such as SKS is any better in this regard. Given that SKS pool is entirely open, it is rather trivial for a single malicious entity to set multiple new keyservers up, and gain advantage over other servers in the pool. In fact, this is probably easier than corrupting the single central server. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From tlikonen at iki.fi Fri Jun 14 16:25:05 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Fri, 14 Jun 2019 17:25:05 +0300 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <6e16b117-c492-f698-f150-095e8720fe74@metacode.biz> (Wiktor Kwapisiewicz via Gnupg-users's message of "Fri, 14 Jun 2019 11:59:16 +0200") References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <6e16b117-c492-f698-f150-095e8720fe74@metacode.biz> Message-ID: <87pnng1by6.fsf@iki.fi> Wiktor Kwapisiewicz [2019-06-14 11:59:16+02] wrote: > Storing endless amounts of data without any kind of verification was a > bad idea. Maybe SKS was designed in good old times when no-one would > try to take advantage of it but in 2019 validating e-mail address is > bare minimum a service such as this should do. > > The current shortcoming is stripping third-party signatures. So Web of > Trust wouldn't work (for good reasons described in the FAQ [0]). For > some people this may be surprising. It may turn out to be a good choice to leave other people's certificates (third-party signatures) out. It seems to solve the storage abuse problem and probably doesn't harm too much communities who need web of trust. Generally web of trust works only in tight communities who can really verify each other's keys. Such communities can easily distribute their keys through their web site or other common resources. For larger audience it's probably enough to have an easy and automatic key discovery and key update service, such as this keys.openpgp.org seems to be. I think. -- /// Teemu Likonen // // PGP: 4E1055DC84E9DFF613D78557719D69D324539450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From sac at 300baud.de Fri Jun 14 16:33:34 2019 From: sac at 300baud.de (Stefan Claas) Date: Fri, 14 Jun 2019 16:33:34 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> Message-ID: Micha? G?rny wrote: > Given that SKS pool is entirely open, it is rather trivial for a single > malicious entity to set multiple new keyservers up, and gain advantage > over other servers in the pool. In fact, this is probably easier than > corrupting the single central server. Fully agree. I proposed a couple of years ago to Phil Zimmermann's Silent Circle*, in Switzerland, to run a modern key server in form like we had with pgp.com. Never received a reply ... *IIRC out of business and Mr. Zimmermann now works afaik for startpage.com, in the Netherlands, and is involved in Openspace. Regards Stefan From konstantin at linuxfoundation.org Fri Jun 14 17:19:30 2019 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Fri, 14 Jun 2019 11:19:30 -0400 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <87pnng1by6.fsf@iki.fi> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <6e16b117-c492-f698-f150-095e8720fe74@metacode.biz> <87pnng1by6.fsf@iki.fi> Message-ID: <20190614151930.GA30753@chatter.i7.local> On Fri, Jun 14, 2019 at 05:25:05PM +0300, Teemu Likonen wrote: >> The current shortcoming is stripping third-party signatures. So Web >> of >> Trust wouldn't work (for good reasons described in the FAQ [0]). For >> some people this may be surprising. > >It may turn out to be a good choice to leave other people's certificates >(third-party signatures) out. It seems to solve the storage abuse >problem and probably doesn't harm too much communities who need web of >trust. Generally web of trust works only in tight communities who can >really verify each other's keys. Such communities can easily distribute >their keys through their web site or other common resources. This is harder than it seems, so inability to use 3rd-party signatures is kind of a deal-breaker. E.g. if you consider a community like Linux kernel, where only very few developers have @kernel.org identities, it would be handy to have a keyserver that did all of the following: 1. implement the regular --send-key --recv-key api 2. when accepting a --send-key, check to make sure at least one of the uid's matches an allow-list of identities (for example, from a dump of all authors/committers in linux.git) 3. perform email verification using the matching identity from #2 4. store all key data without stripping out 3rd-party signatures I guess it would be easy enough to hack that into hagrid, but that would mean a hard fork and I'd avoid that at all costs. -K From wiktor at metacode.biz Sat Jun 15 22:30:25 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Sat, 15 Jun 2019 22:30:25 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <20190614151930.GA30753@chatter.i7.local> Message-ID: Hi Konstantin, On Fri Jun 14, 2019 at 11:19 AM Konstantin Ryabitsev wrote: > 1. implement the regular --send-key --recv-key api This is already implemented. > 2. when accepting a --send-key, check to make sure at least one of the > uid's matches an allow-list of identities (for example, from a dump of > all authors/committers in linux.git) I guess this could be implemented as a white-list of e-mails. I hope you don't mind but I've mentioned this use-case on their issue tracker: https://gitlab.com/hagrid-keyserver/hagrid/issues/55#note_181698023 > 3. perform email verification using the matching identity from #2 If filtering would be implemented this would also work as is. > 4. store all key data without stripping out 3rd-party signatures As far as I understood the Hagrid keyserver developers they're not against 3rd-party signatures per se, just don't like the idea of anyone appending data to keys. The answer on the FAQ seems quite open: https://keys.openpgp.org/about/faq#third-party-signatures > I guess it would be easy enough to hack that into hagrid, but that would > mean a hard fork and I'd avoid that at all costs. I think it would be useful to bring it to Hagrid developers (either on the issue tracker, via e-mail or #hagrid on IRC). From my experience they're listening to feedback :) Have a nice evening! Kind regards, Wiktor -- https://metacode.biz/@wiktor From look at my.amazin.horse Sun Jun 16 00:10:54 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Sun, 16 Jun 2019 00:10:54 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <20190614151930.GA30753@chatter.i7.local> Message-ID: <3TN4V390MN3LS.2CJOU3EWS4KDY@my.amazin.horse> Hi Konstantin, > This is harder than it seems, so inability to use 3rd-party signatures is kind > of a deal-breaker. Sure is. There are ways to solve this problem, but at the moment they are all at an early conceptual state at best. For example, we could allow third-party signatures if they are cross-signed by the signee (in an unhashed subpacket, for example). Assuming a caff-style workflow, this would be a fairly minor change to user workflows, and solve the abuse issue because the owner of each key remains in charge of any signatures published for it. Wiktor also suggested before to accept key material from signed upload requests (roughly "gpg --export keyid | gpg --sign-as keyid | curl). But I'm unsure of how well this can really work in practice, given how hard it is to keep one's local keyring in any kind of clean state. Of course, closed user groups with different trust models and abuse circumstances can solve this much more easily. > I guess it would be easy enough to hack that into hagrid, but that would mean > a hard fork and I'd avoid that at all costs. Maintaining hagrid for the keys.openpgp.org use case takes up all the free time I can spend on this project - which is why it is currently built to do exactly that, no more no less. I would be open to contributions that allowed the use of hagrid in other scenarios such as this. More eyes on the code base sure wouldn't hurt. (I would also probably be available for commissions, if you're into that :) Note that, for better or worse, hagrid uses a filesystem-based database. We maintain all keys in the filesystem, and route most requests directly from nginx, and the rest via x-accel-redirect. This is not something everybody is comfortable with, so beware ;) - V From look at my.amazin.horse Sat Jun 15 23:41:19 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Sat, 15 Jun 2019 23:41:19 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: Message-ID: Message-ID: <2KU5AOG1H4J1S.2SEALATU74I71@my.amazin.horse> > For a start, it only supports email userids - so it is incompatible with > monkeysphere. Indeed! This is a use case that would be interesting to explore though, feel free to open an issue on our tracker if you want to help think it through! > It's also a centralised resource, meaning it's not resilient enough for > distributing revocations, which is the main use case for SKS these days Is "resilient" really a word you would use to describe SKS these days? Are you aware of issues like this?: https://bitbucket.org/skskeyserver/sks-keyserver/issues/57/anyone-can-make-any-pgp-key-unimportable - V From sac at 300baud.de Sun Jun 16 10:00:33 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 16 Jun 2019 10:00:33 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <20190614151930.GA30753@chatter.i7.local> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <6e16b117-c492-f698-f150-095e8720fe74@metacode.biz> <87pnng1by6.fsf@iki.fi> <20190614151930.GA30753@chatter.i7.local> Message-ID: Konstantin Ryabitsev wrote: > On Fri, Jun 14, 2019 at 05:25:05PM +0300, Teemu Likonen wrote: > >> The current shortcoming is stripping third-party signatures. So Web > >> of > >> Trust wouldn't work (for good reasons described in the FAQ [0]). For > >> some people this may be surprising. > > > >It may turn out to be a good choice to leave other people's certificates > >(third-party signatures) out. It seems to solve the storage abuse > >problem and probably doesn't harm too much communities who need web of > >trust. Generally web of trust works only in tight communities who can > >really verify each other's keys. Such communities can easily distribute > >their keys through their web site or other common resources. > > This is harder than it seems, so inability to use 3rd-party signatures > is kind of a deal-breaker. E.g. if you consider a community like Linux > kernel, where only very few developers have @kernel.org identities, it > would be handy to have a keyserver that did all of the following: > > 1. implement the regular --send-key --recv-key api > 2. when accepting a --send-key, check to make sure at least one of the > uid's matches an allow-list of identities (for example, from a dump of > all authors/committers in linux.git) > 3. perform email verification using the matching identity from #2 > 4. store all key data without stripping out 3rd-party signatures > > I guess it would be easy enough to hack that into hagrid, but that would > mean a hard fork and I'd avoid that at all costs. Maybe you can consider in the future at least to allow CA sigs. Those would be only one sig per key and the CA signing keys could be stored in your database as reference as well. Currently 3 CAs come to mind: Governikus, Heise and CAcert. Maybe other CAs will show up in the future if you model would support it and then we don't have to deal with the classical WoT anymore. Well, only a suggestion! Regards Stefan From look at my.amazin.horse Sun Jun 16 13:51:33 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Sun, 16 Jun 2019 13:51:33 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <6e16b117-c492-f698-f150-095e8720fe74@metacode.biz> <87pnng1by6.fsf@iki.fi> <20190614151930.GA30753@chatter.i7.local> Message-ID: <2R668OJM0L2K3.20CGNEGFLVNUA@my.amazin.horse> > Maybe you can consider in the future at least to allow CA sigs. > Those would be only one sig per key and the CA signing keys > could be stored in your database as reference as well. > > Currently 3 CAs come to mind: Governikus, Heise and CAcert. Interesting thought! I would be a bit worried about slipping into a gatekeeper role, but at least there are no technical issues with this. - V From andrewg at andrewg.com Sun Jun 16 14:49:30 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 16 Jun 2019 13:49:30 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <2R668OJM0L2K3.20CGNEGFLVNUA@my.amazin.horse> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <6e16b117-c492-f698-f150-095e8720fe74@metacode.biz> <87pnng1by6.fsf@iki.fi> <20190614151930.GA30753@chatter.i7.local> <2R668OJM0L2K3.20CGNEGFLVNUA@my.amazin.horse> Message-ID: <245D64B7-3E47-4F4A-B628-DB3ED2F5C999@andrewg.com> > On 16 Jun 2019, at 12:51, Vincent Breitmoser wrote: > > >> Maybe you can consider in the future at least to allow CA sigs. >> Those would be only one sig per key and the CA signing keys >> could be stored in your database as reference as well. >> >> Currently 3 CAs come to mind: Governikus, Heise and CAcert. > > Interesting thought! I would be a bit worried about slipping into a gatekeeper > role, but at least there are no technical issues with this. I would recommend that if you want to go down the road of selectively allowing some third party sigs, that the only honest and transparent way is to allow the leaf certs to determine which sigs are allowed on themselves, via cross signing. If a CA wants to make this process cleaner for the end user, it can be done through tooling. A From andrewg at andrewg.com Sun Jun 16 15:00:10 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 16 Jun 2019 14:00:10 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <2KU5AOG1H4J1S.2SEALATU74I71@my.amazin.horse> References: <2KU5AOG1H4J1S.2SEALATU74I71@my.amazin.horse> Message-ID: <812C4324-DD69-442B-B3B7-843B4BD51EE6@andrewg.com> > On 15 Jun 2019, at 22:41, Vincent Breitmoser wrote: > > >> For a start, it only supports email userids - so it is incompatible with >> monkeysphere. > > Indeed! This is a use case that would be interesting to explore though, feel > free to open an issue on our tracker if you want to help think it through! I will when I get back to a desktop, thanks. My first thought would be to use domain verification, as in ACME. No point reinventing the wheel. >> It's also a centralised resource, meaning it's not resilient enough for >> distributing revocations, which is the main use case for SKS these days > > Is "resilient" really a word you would use to describe SKS these days? Are you > aware of issues like this?: I?m well aware of the limitations of SKS. I spammed the SKS list last year re modifying the reconciliation algorithm to prevent transmission of problematic key packets (tl;dr: it?s harder than it looks). My main concern has always been how to reliably distribute revocations; this is a Very Hard problem that other PKIs have also struggled with, and the ?optimum? solution is heavily dependent on your threat model. But even so, SKS worked really well up until relatively recently. A From sac at 300baud.de Sun Jun 16 16:10:34 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 16 Jun 2019 16:10:34 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <2R668OJM0L2K3.20CGNEGFLVNUA@my.amazin.horse> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <6e16b117-c492-f698-f150-095e8720fe74@metacode.biz> <87pnng1by6.fsf@iki.fi> <20190614151930.GA30753@chatter.i7.local> <2R668OJM0L2K3.20CGNEGFLVNUA@my.amazin.horse> Message-ID: Vincent Breitmoser wrote: > > > Maybe you can consider in the future at least to allow CA sigs. > > Those would be only one sig per key and the CA signing keys > > could be stored in your database as reference as well. > > > > Currently 3 CAs come to mind: Governikus, Heise and CAcert. > > Interesting thought! I would be a bit worried about slipping into a > gatekeeper role, but at least there are no technical issues with this. Thanks for your reply! I think this would be also appreciated by the CAs, in case they decide later to run your key server software as well, or for companies etc. whishing to having their own CA and using your key server software too. Regards Stefan From ageyev at gmail.com Sun Jun 16 15:05:41 2019 From: ageyev at gmail.com (Viktor Ageyev) Date: Sun, 16 Jun 2019 16:05:41 +0300 Subject: OpenPGP key verification + legal framework In-Reply-To: <1882251501.20181110114045@my_localhost_LG> References: <67FD4C95-95EE-4A9D-B05C-8F567D849639@cleanfuels.nl> <054ed41f-adc4-737b-0858-8c6f7a9c70fd@metacode.biz> <28f5b8c2-06a3-840e-b259-d507021675e6@metacode.biz> <3a728ad3-b631-ec75-2bfc-aec6b6f153f2@bruckner.tk> <768d676f-de19-be26-e5c8-bb6bd8a0faaf@gmail.com> <2730fd8e-2fcb-581d-ab1d-c3065c8b317a@metacode.biz> <5950ae29-1a13-36bc-d514-ca5f353a3ff1@gmail.com> <1882251501.20181110114045@my_localhost_LG> Message-ID: <9f78c645-7eec-691c-9db6-1de1ad547ad3@gmail.com> On 10/11/2018 13:40, MFPA wrote: > Many people would not be prepared to do this because Google now > demands a phone number in their sign-up process. Nobody needs a phone > number in order to provide an email account, it is just an additional > piece of personal information for Google to abuse. We also require phone number check to verify user identity. If you want to stay anonymous, you can not verify your identity. >> It doesn't seem to me that every internet site should >> have its own >> separate login-password system, in most cases it is >> better to use the >> existing secure solution. > > Too many eggs, too few baskets. Crack the user's login on one site and > you've cracked it on all. Most logins connected to email. Crack email, and you got them all. What is the difference if you use the same login as for email? Best regards, Viktor Ageyev From robbat2 at gentoo.org Mon Jun 17 01:19:39 2019 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Sun, 16 Jun 2019 23:19:39 +0000 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <20190616143257.CDB1934622C@smtp.gentoo.org> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <6e16b117-c492-f698-f150-095e8720fe74@metacode.biz> <87pnng1by6.fsf@iki.fi> <20190614151930.GA30753@chatter.i7.local> <2R668OJM0L2K3.20CGNEGFLVNUA@my.amazin.horse> <20190616143257.CDB1934622C@smtp.gentoo.org> Message-ID: On Sun, Jun 16, 2019 at 04:10:34PM +0200, Stefan Claas wrote: > Vincent Breitmoser wrote: > > > > > > Maybe you can consider in the future at least to allow CA sigs. > > > Those would be only one sig per key and the CA signing keys > > > could be stored in your database as reference as well. > > > > > > Currently 3 CAs come to mind: Governikus, Heise and CAcert. > > > > Interesting thought! I would be a bit worried about slipping into a > > gatekeeper role, but at least there are no technical issues with this. > > Thanks for your reply! I think this would be also appreciated > by the CAs, in case they decide later to run your key server > software as well, or for companies etc. whishing to having their > own CA and using your key server software too. Yes, from the perspective of Gentoo Linux, we've recently spun up dedicated keyservers intended for @gentoo.org keys only. And being able to include our own CA for approved signatures would fit well with future plans. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robbat2 at gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1113 bytes Desc: not available URL: From patrick at enigmail.net Tue Jun 18 13:05:38 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Tue, 18 Jun 2019 13:05:38 +0200 Subject: Invitation to the 5th OpenPGP Email Summit Message-ID: I'm happy to announce the 5th OpenPGP Email Summit which will take place Saturday, October 12 until Sunday, October 13, 2019 in Berlin (Germany) at the Onion Space. Last year, the idea came up that it would be nice if some of the topics discussed could directly be prototyped. I have therefore booked the Onion Space for Monday and Tuesday (October 14/15), such that those who are interested can directly start working on their product. ABOUT THE OpenPGP EMAIL SUMMIT ============================== This is an event open for anybody involved in the development of email clients using OpenPGP for encryption, and related software. We already had four OpenPGP Email Summits at various locations in Europe. These are meetings by technical experts of projects and tools dealing with OpenPGP with a focus on email encryption. The goals are to better get to know each other, and to discuss and work on several technical issues that hopefully improve certain aspects of OpenPGP-based email encryption. For details, see https://wiki.gnupg.org/OpenPGPEmailSummits REGISTRATION ============ If you want to attend, please *send an informal email* to: patrick at enigmail.net Please let me know if you plan to stay on Monday and/or Tuesday. If you need funding for your travel/hotel expenses, then please get in contact with me. NOTES ===== This is a meeting of those who develop software. Thus, we will have a lot of tech talk about key servers, key exchange, subject encryption, password recovery, etc. If you just are interested in these topics as a user, you probably will be bored to death . Thus, feel free to join us if you are working in the area of - TECHNICAL DETAILS - for SENDING or PROCESSING ENCRYPTED EMAILS - with OpenPGP - in a project or product. Note however, that due to capacity reasons we cannot have more than 1-2 people from each project. We can host about 30 attendees. Note that this is still neither a well-organized conference nor a commercial meeting. The agenda will be driven by the attendees. Anyone may propose any topic for discussion, as long as he/she is ready to lead the discussion. More details are/will be available on the web site: https://wiki.gnupg.org/OpenPGPEmailSummit201910 Looking forward to meeting you in Berlin -Patrick -- Patrick Brunschwig mailto:patrick at enigmail.net PGP fingerprint: 4F9F 89F5 505A C1D1 A260 631C DB11 87B9 DD5F 693B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From elowe at elowe.com Wed Jun 19 00:53:59 2019 From: elowe at elowe.com (Earle Lowe) Date: Tue, 18 Jun 2019 15:53:59 -0700 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Fri, Jun 14, 2019 at 7:35 AM Stefan Claas wrote: > > > Fully agree. I proposed a couple of years ago to Phil Zimmermann's > Silent Circle*, in Switzerland, to run a modern key server in form > like we had with pgp.com. Never received a reply ... > > *IIRC out of business and Mr. Zimmermann now works afaik for > startpage.com, in the Netherlands, and is involved in Openspace. > > Regards > Stefan Silent Circle is still in business (AFAIK) - but they don't make phones anymore, a software-only company now. And keyserver.pgp.com is definately still around (the much-maligned Global Directory) - which interestingly enough does a number of things the new key server does, like email verification, enforcing one email one key, stripping off signatures, one can remove keys, and zero federation with other key servers. -Earle From fernan.aguero at gmail.com Wed Jun 19 15:50:37 2019 From: fernan.aguero at gmail.com (Fernan Aguero) Date: Wed, 19 Jun 2019 10:50:37 -0300 Subject: help with missing keys Message-ID: Hi, I've been using gnupg just fine for a while (gpg, then moved to gpg2, created new keys), mostly to encrypt/sign password using the pass (zx2c4) passwordstore. Then all of a sudden things broke and I cannot decrypt things, even though keys are apparently there ... I'd appreciate some help in trying to recover my system. Any clues on what may be going on? This is Ubuntu 16.04. $ gpg2 --list-secret-keys /home/fernan/.gnupg/pubring.kbx ------------------------------- sec rsa4096/5DCD6D91 2019-01-23 [SC] uid [ultimate] Fernan Aguero (personal gmail) < fernan.aguero at gmail.com> ssb rsa4096/AD08B3BC 2019-01-23 [E] $ gpg2 --decrypt file.gpg gpg: encrypted with 4096-bit RSA key, ID AD08B3BC, created 2019-01-23 "Fernan Aguero (personal gmail) " gpg: public key decryption failed: No such file or directory gpg: decryption failed: No secret key $ ls -la ~/.gnupg/ total 156 drwx------ 5 fernan fernan 4096 Jun 19 10:27 . drwxr-xr-x 139 fernan fernan 20480 Jun 19 10:21 .. drwx------ 2 fernan fernan 4096 Dec 16 2016 crls.d -rw------- 1 fernan fernan 9419 Jun 19 10:27 gpg.conf -rw-rw-r-- 1 fernan fernan 0 Jan 23 10:39 .gpg-v21-migrated drwx------ 2 fernan fernan 4096 Jan 23 10:51 openpgp-revocs.d drwx------ 2 fernan fernan 4096 Jan 23 10:51 private-keys-v1.d -rw------- 1 fernan fernan 43438 May 6 13:59 pubring.gpg -rw------- 1 fernan fernan 43438 May 6 13:59 pubring.gpg~ -rw-rw-r-- 1 fernan fernan 2408 Jan 23 10:51 pubring.kbx -rw------- 1 fernan fernan 32 Dec 16 2016 pubring.kbx~ -rw------- 1 fernan fernan 600 Jun 12 12:05 random_seed -rw------- 1 fernan fernan 0 Oct 29 2012 secring.gpg srwx------ 1 fernan fernan 0 Jun 19 10:31 S.gpg-agent -rw------- 1 fernan fernan 1280 May 9 14:11 trustdb.gpg -- fernan -------------- next part -------------- An HTML attachment was scrubbed... URL: From vijaikumar.kanagarajan at gmail.com Tue Jun 18 10:03:45 2019 From: vijaikumar.kanagarajan at gmail.com (vijai kumar) Date: Tue, 18 Jun 2019 04:03:45 -0400 Subject: Change socketdir from ~/.gnupg to /run/user/ In-Reply-To: <20190617135821.GA1297@osboxes> References: <20190617135821.GA1297@osboxes> Message-ID: Hi, I am using gpg inside a docker container. By default, there is no /run/user/ in the container so gpg defaults to ~/.gnupg as socket directory. Is there a provision to change the socket directory later? Now, I would like to create /run/user/$(id -u)/gnupg and use this as the default socket directory. Is there a way to kill the existing agent and relaunch it with the new socket directory? Thanks, Vijai Kumar K From user_jdlcb at tuta.io Thu Jun 20 03:01:23 2019 From: user_jdlcb at tuta.io (user_jdlcb at tuta.io) Date: Thu, 20 Jun 2019 03:01:23 +0200 (CEST) Subject: "clipboard contains no valid encryption data" Message-ID: A while back I installed gpa (GnuPrivacyAssistant) in the Linux container on my Chromebook. Getting it up and running was straight forward. Recently I found it necessary to powerwash the same Chromebook and upon reinstalling gpa and importing my keys found that when I tried to decrypt I received an error message saying that ?clipboard contains no valid encryption data?. I?ve found 5 year old Reddit posts that site the same issue but not concrete suggestions to alleviate the issue. As well, a search on duckduckgo hasn?t turned up anything. Anybody have any suggestions??? Thanks in advance. My PGP Public Key Fingerprint; B120 B64D 51E9 1AC2 461F 31DB CE14 24B6 4D8C 56BB? Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: https://tutanota.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From guru at unixarea.de Fri Jun 21 13:20:17 2019 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 21 Jun 2019 11:20:17 +0000 Subject: GnuPG and SSH_AUTH_SOCK value Message-ID: <20190621112017.GA2077@c720-r349041> Hello, I'm using GnuPG together with an OpenPGP card among other things for ssh access. The SSH_AUTH_SOCK value is to be set like this # set SSH_AUTH_SOCK # unset SSH_AGENT_PID unset SSH_AUTH_SOCK SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"; export SSH_AUTH_SOCK What I do not understand is, why this value without the KDE5 environment is $ gpgconf --list-dirs agent-ssh-socket /home/guru/.gnupg-ccid/S.gpg-agent.ssh and after start of Xorg and KDE5 it is: $ gpgconf --list-dirs agent-ssh-socket /var/run/user/1001/gnupg/d.m4rfaasqebhjmgto9ddm6m7y/S.gpg-agent.ssh Why is this change/difference? matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: ???????? ????????????! Thank you very much, Russian liberators! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From juergen at bruckner.tk Fri Jun 21 12:03:25 2019 From: juergen at bruckner.tk (Juergen Bruckner) Date: Fri, 21 Jun 2019 12:03:25 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Hey all, here is a article (only in german) from Heise: https://www.heise.de/security/meldung/Neuer-OpenPGP-Keyserver-liefert-endlich-verifizierte-Schluessel-4450814.html regards Juergen Am 19.06.19 um 00:53 schrieb Earle Lowe via Gnupg-users: > On Fri, Jun 14, 2019 at 7:35 AM Stefan Claas wrote: >> >> >> Fully agree. I proposed a couple of years ago to Phil Zimmermann's >> Silent Circle*, in Switzerland, to run a modern key server in form >> like we had with pgp.com. Never received a reply ... >> >> *IIRC out of business and Mr. Zimmermann now works afaik for >> startpage.com, in the Netherlands, and is involved in Openspace. >> >> Regards >> Stefan > > Silent Circle is still in business (AFAIK) - but they don't make > phones anymore, a software-only company now. > > And keyserver.pgp.com is definately still around (the much-maligned > Global Directory) - which interestingly enough does a number of things > the new key server does, like email verification, enforcing one email > one key, stripping off signatures, one can remove keys, and zero > federation with other key servers. > > -Earle > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Juergen M. Bruckner juergen at bruckner.tk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From look at my.amazin.horse Fri Jun 21 12:24:26 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Fri, 21 Jun 2019 12:24:26 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <264MTQHXAUG4F.3RXARZFYPAJE2@my.amazin.horse> Pretty happy with how this turned out so far. :) Feedback I received was almost universally positive, other than the folks on heise comments who really really really like the Web of Trust. In particular, I heard of almost no isues with the verification flow, which hopefully means things "just work" for everybody. The heise article helped a lot getting the word out, we are closing in on 2k verified email addresses: https://keys.openpgp.org/about/stats/week.png With the patch I recently submitted to gnupg-devel, `--refresh-keys` works very smoothly for me. I wouldn't say it's blazingly fast, but my 320 keys take about two minutes to refresh, and almost all of that time is spent in dirmngr. The patch is already applied in Debian experimental, but hopefully we can get it upstream soon as well. For those who want to give it a shot: https://lists.gnupg.org/pipermail/gnupg-devel/2018-October/033969.html - V From jhs at berklix.com Fri Jun 21 13:37:54 2019 From: jhs at berklix.com (Julian H. Stacey) Date: Fri, 21 Jun 2019 13:37:54 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: Your message "Fri, 21 Jun 2019 12:03:25 +0200." Message-ID: <201906211138.x5LBbsQ3087089@fire.js.berklix.net> > From: Juergen Bruckner via Gnupg-users > Hey all, > here is a article (only in german) from Heise: > > https://www.heise.de/security/meldung/Neuer-OpenPGP-Keyserver-liefert-end= > lich-verifizierte-Schluessel-4450814.html English: https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%2Fwww.heise.de%2Fsecurity%2Fmeldung%2FNeuer-OpenPGP-Keyserver-liefert-endlich-verifizierte-Schluessel-4450814.html Translate engines I know of: http://www.berklix.org/trans/ if others please mail me. Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent 700,000 Brexit votes stolen from British in EU. 1.9 M UK young had no vote & 1.3 M died since. Paid Lies. Foreign funders fined. http://stolenvotes.uk From wk at gnupg.org Fri Jun 21 15:13:45 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Jun 2019 15:13:45 +0200 Subject: GnuPG and SSH_AUTH_SOCK value In-Reply-To: <20190621112017.GA2077@c720-r349041> (Matthias Apitz's message of "Fri, 21 Jun 2019 11:20:17 +0000") References: <20190621112017.GA2077@c720-r349041> Message-ID: <87muibozcm.fsf@wheatstone.g10code.de> On Fri, 21 Jun 2019 11:20, guru at unixarea.de said: > What I do not understand is, why this value without the KDE5 environment > is > > $ gpgconf --list-dirs agent-ssh-socket > /home/guru/.gnupg-ccid/S.gpg-agent.ssh That is because you have a GNUPGHOME=/home/guru/.gnupg-ccid and /var/run/users/1001 does not exist. > and after start of Xorg and KDE5 it is: > > $ gpgconf --list-dirs agent-ssh-socket > /var/run/user/1001/gnupg/d.m4rfaasqebhjmgto9ddm6m7y/S.gpg-agent.ssh /var/run/users/1001 has been created (systemd mess?) and thus GnuPG expects ist sockets below /var/run/user/. The token is the hash of the homedir's name so that we don't get a too long path. $ echo -n /home/guru/.gnupg-ccid | sha1sum | cut -d ' ' -f1 | undump |zb32 m4rfaasqebhjmgto9ddm6m7yfhgj8yc8 undump does the obvious and zb32 is like base64 but encodes using Zooko's Base32 encoding. Shalom-Salam, Werner ps: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=wk-misc.git;a=blob;f=zb32.c https://git.gnupg.org/cgi-bin/gitweb.cgi?p=wk-misc.git;a=blob;f=undump.c -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Fri Jun 21 15:32:24 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Jun 2019 15:32:24 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: (Juergen Bruckner via Gnupg-users's message of "Fri, 21 Jun 2019 12:03:25 +0200") References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <87fto3oyhj.fsf@wheatstone.g10code.de> On Fri, 21 Jun 2019 12:03, gnupg-users at gnupg.org said: > here is a article (only in german) from Heise: By the very same guy who showed in the past that he has no clue about keyservers and their goals and ignored all comments gathered about this before writing an article [1]. That new thing now is the n-th repetition of the same game: Replacing PGP by a centralized approach, or well many centralized approaches, in an attempt to repeat the story of S/MIME. PGP has its strengths in the idea of not having the one-and-only-distributor-of-all-keys and thus a SPoFailure/Denial/Surveillance. If we want that it is easier to go with S/MIME. An in-house keyserver is sometimes a good idea but a global validating keyserver is a failed idea. Being under the AGPL may also be problematic because the code can't be used for in-house deployments and the AGPL often smells a little bit like a trigger for an Open Core business model. Salam-Shalom, Werner [1] https://werner.eifzilla.de/20150224-re-die-schlssel-falle.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Fri Jun 21 15:49:40 2019 From: sac at 300baud.de (Stefan Claas) Date: Fri, 21 Jun 2019 15:49:40 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <87fto3oyhj.fsf@wheatstone.g10code.de> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> Message-ID: Werner Koch via Gnupg-users wrote: > That new thing now is the n-th repetition of the same game: Replacing > PGP by a centralized approach, or well many centralized approaches, in > an attempt to repeat the story of S/MIME. PGP has its strengths in the > idea of not having the one-and-only-distributor-of-all-keys and thus a > SPoFailure/Denial/Surveillance. If we want that it is easier to go with > S/MIME. > > An in-house keyserver is sometimes a good idea but a global validating > keyserver is a failed idea. Being under the AGPL may also be > problematic because the code can't be used for in-house deployments and > the AGPL often smells a little bit like a trigger for an Open Core > business model. I think it is a very good idea from Vincent and the Sequoia team to start new things! The GnuPG and SKS ecosystem is not or was not capable to come up with an adequate replacement for SKS. Therefore kudos and big applause to Vincent and his team! Regards Stefan From andrewg at andrewg.com Fri Jun 21 16:26:17 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 21 Jun 2019 15:26:17 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <87fto3oyhj.fsf@wheatstone.g10code.de> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> Message-ID: <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> On 21/06/2019 14:32, Werner Koch via Gnupg-users wrote: > That new thing now is the n-th repetition of the same game: Replacing > PGP by a centralized approach, or well many centralized approaches, in > an attempt to repeat the story of S/MIME. PGP has its strengths in the > idea of not having the one-and-only-distributor-of-all-keys and thus a > SPoFailure/Denial/Surveillance. If we want that it is easier to go with > S/MIME. If hagrid supported an SKS-like reconciliation protocol, would that mitigate your concerns? -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From guru at unixarea.de Fri Jun 21 18:39:38 2019 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 21 Jun 2019 16:39:38 +0000 Subject: GnuPG and SSH_AUTH_SOCK value In-Reply-To: <87muibozcm.fsf@wheatstone.g10code.de> References: <20190621112017.GA2077@c720-r349041> <87muibozcm.fsf@wheatstone.g10code.de> Message-ID: <20190621163938.GA2175@c720-r349041> El d?a viernes, junio 21, 2019 a las 03:13:45p. m. +0200, Werner Koch via Gnupg-users escribi?: > On Fri, 21 Jun 2019 11:20, guru at unixarea.de said: > > > What I do not understand is, why this value without the KDE5 environment > > is > > > > $ gpgconf --list-dirs agent-ssh-socket > > /home/guru/.gnupg-ccid/S.gpg-agent.ssh > > That is because you have a > GNUPGHOME=/home/guru/.gnupg-ccid > and /var/run/users/1001 does not exist. > > > and after start of Xorg and KDE5 it is: > > > > $ gpgconf --list-dirs agent-ssh-socket > > /var/run/user/1001/gnupg/d.m4rfaasqebhjmgto9ddm6m7y/S.gpg-agent.ssh > > /var/run/users/1001 has been created (systemd mess?) and thus GnuPG > expects ist sockets below /var/run/user/. The token is the hash of > the homedir's name so that we don't get a too long path. Thanks for the explanation. But why GNUPGHOME is not also used for the place where the sockets should be created when X11/KDE is up? matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: ???????? ????????????! Thank you very much, Russian liberators! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From Jennifer.Mead at pacificorp.com Fri Jun 21 20:42:28 2019 From: Jennifer.Mead at pacificorp.com (Mead, Jennifer) Date: Fri, 21 Jun 2019 18:42:28 +0000 Subject: GPG/YubiKey/CentOS7 Message-ID: <6b4009746ab846fba1586d61a706f3db@SLCMBXW04VP.pacificorp.us> Hi All, Even though I have had GPG and YubiKey running a few times on CentOS7 I lost all my notes and install guides. I am hung up on getting the public key from the YubiKey. I wrote the gpg keys right on the yubikey, I can query and see that gnupg knows all about it and sees it as a card. /home/p42547/.gnupg/pubring.gpg ------------------------------- pub 2048R/C5778901 2019-06-20 uid Jen Mead (yubikey) sub 2048R/8293401A 2019-06-20 sub 2048R/A558FD7E 2019-06-20 [p42547 at cswks20~] > gpg --list-secret-keys /home/p42547/.gnupg/secring.gpg ------------------------------- sec> 2048R/C5778901 2019-06-20 Card serial no. = 0006 09042340 uid Jen Mead (yubikey) ssb> 2048R/8293401A 2019-06-20 ssb> 2048R/A558FD7E 2019-06-20 [p42547 at cswks20~] > ssh-add [p42547 at cswks20~] > ssh-add -l error fetching identities for protocol 1: agent refused operation 2048 SHA256:dj02A/DHL0RKuJuMLBX14CaQ6RriT0uqY0sXqTNPoW4 cardno:000609042340 (RSA) [p42547 at cswks20~] > gpg --export-secret-keys $KEYID | openpgp2ssh $KEYID We cannot handle encrypted secret keys. Skipping! I never encrypted this key. So why is it coming out encrypted? gpg --export-secret-keys C5778901 gives me an asci file that then complains about not being openpgp it also is missing the cardno in the public file which tells the server to look at the yubikey for the matching key. I am more than confused. Can anyone tell me how to properly get the public key off of the yubikey to present to other servers? Regards, Jennifer (Jen) Mead Security Engineer 503.813.5373 Jennifer.Mead at pacificorp.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Fri Jun 21 22:49:30 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 21 Jun 2019 16:49:30 -0400 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> Message-ID: <87ef3my885.fsf@fifthhorseman.net> On Fri 2019-06-21 15:26:17 +0100, Andrew Gallagher wrote: > On 21/06/2019 14:32, Werner Koch via Gnupg-users wrote: >> That new thing now is the n-th repetition of the same game: Replacing >> PGP by a centralized approach, or well many centralized approaches, in >> an attempt to repeat the story of S/MIME. PGP has its strengths in the >> idea of not having the one-and-only-distributor-of-all-keys and thus a >> SPoFailure/Denial/Surveillance. If we want that it is easier to go with >> S/MIME. > > If hagrid supported an SKS-like reconciliation protocol, would that > mitigate your concerns? There might be an impedance mismatch here, depending on what you think the goals are. SKS has no validation policy by default, and SKS-style reconciliation assumes that all peers have the exact same filtering policy. So: what exactly is the data that these servers would reconcile between each other? Since multiple validating keyservers haven't actually seen the same validation steps, it's not clear how they'd decide what to filter in terms of validated data. it may help to think about the different sorts of things that people use keyservers for. we don't have to solve all different use cases at once. I've written quite a bit more technical detail over here: https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-03 But there are basically three main use cases for OpenPGP keyserver clients (i'm setting aside the use case of people who want to publish their certificates): a) validating a signature that comes from a certificate that the user doesn't yet have access to. b) finding a certificate to associated with a peer the user wants to communicate with (e.g. lookup by e-mail address). c) learning about the status of a certificate that the user already has (expiration, revocation, new subkeys, etc) There's a good argument to be made that use case (a) is simply a broken workflow. If i'm shipping you a signature, and i have no way of ensuring that you already know my certificate, i can just ship my certificate along with the signature. If i don't do that, and you can't verify the signature, it's not clear that any keyserver network *should* be the thing to solve that problem. Use case (b) is intimately tied to the address validation process, which introduces the set reconciliation difficulty i allude to above. (b) is also well-suited to distributed discovery mechanisms, like DNS OPENPGPKEY or WKD, at least for users of domains that are willing to offer such a delegated publication mechanism. so it might not be a necessary component for a keyserver network long-term. But the data required for use case (c) on its own is eminently reconcilable, with relatively simple and clear filtering logic, and is likely the most worrisome part for the SPoFailure/Denial/Surveillance concerns that Werner rightly raises. So if we decide we only want to address use case (c), then it doesn't seem too crazy to imagine reconciliation among multiple installations of all the distributed, cryptographically-validated *non-identity* data that hagrid is designed to distribute. And this should be fully-compatible with hagrid's implementation; each instance which can simply augment the reconciled data with the identity information that it has independently verified. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wolfgang.traylor at posteo.de Sat Jun 22 09:41:46 2019 From: wolfgang.traylor at posteo.de (Wolfgang Traylor) Date: Sat, 22 Jun 2019 09:41:46 +0200 Subject: GPG/YubiKey/CentOS7 In-Reply-To: <6b4009746ab846fba1586d61a706f3db@SLCMBXW04VP.pacificorp.us> References: <6b4009746ab846fba1586d61a706f3db@SLCMBXW04VP.pacificorp.us> Message-ID: <20190622074144.z6nm54f2likjbhs6@gruenfink> Hello Jen, > gpg --export-secret-keys $KEYID | openpgp2ssh $KEYID After moving your secret subkeys to a smartcard, the secret subkeys are not on your hard drive anymore. The secret parts are only on the smartcard then. And for security reasons you cannot export secret keys from your smartcard. The files of your secret keys you find in `~/.gnupg/private-keys-v1.d/` on your hard drive are only ?stubs?. > Can anyone tell me how to properly get the public key off of the yubikey to present to other servers? The smartcard only stores the secret parts of your subkeys, not the public parts. In order to use your GPG subkey (which has authentication function) for SSH, you can use `gpg --export-ssh-key ` command. This will give you the public part your authentication key in SSH format. For this command you only need the public key in your keyring. The export has nothing to do with your smartcard. I attached a little tutorial I once wrote for using GnuPG for SSH authentication. It worked for me on Arch Linux, Manjaro, and Linux Mint, but should apply to CentOS, too. Best regards, W. Traylor -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg_for_ssh.md Type: text/markdown Size: 3232 bytes Desc: not available URL: From wk at gnupg.org Sat Jun 22 09:47:12 2019 From: wk at gnupg.org (Werner Koch) Date: Sat, 22 Jun 2019 09:47:12 +0200 Subject: GnuPG and SSH_AUTH_SOCK value In-Reply-To: <20190621163938.GA2175@c720-r349041> (Matthias Apitz's message of "Fri, 21 Jun 2019 16:39:38 +0000") References: <20190621112017.GA2077@c720-r349041> <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041> Message-ID: <874l4ioydb.fsf@wheatstone.g10code.de> On Fri, 21 Jun 2019 16:39, guru at unixarea.de said: > Thanks for the explanation. But why GNUPGHOME is not also used for the > place where the sockets should be created when X11/KDE is up? That seems to be deep in the innards of KDE's X startup or Wayland or Systemd configuration. I try to avoid all this and use the old fashioned but easy to debug ~/.xsession Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Sat Jun 22 10:04:09 2019 From: wk at gnupg.org (Werner Koch) Date: Sat, 22 Jun 2019 10:04:09 +0200 Subject: GPG/YubiKey/CentOS7 In-Reply-To: <6b4009746ab846fba1586d61a706f3db@SLCMBXW04VP.pacificorp.us> (Jennifer via Gnupg-users Mead's message of "Fri, 21 Jun 2019 18:42:28 +0000") References: <6b4009746ab846fba1586d61a706f3db@SLCMBXW04VP.pacificorp.us> Message-ID: <87zhmanj0m.fsf@wheatstone.g10code.de> On Fri, 21 Jun 2019 18:42, gnupg-users at gnupg.org said: > Even though I have had GPG and YubiKey running a few times on CentOS7 Which GnuPG version does it come with: "gpg --version". Does it install gpg under the name gpg2 and provides the legacy GnuPG 1.4 under the name gpg ? > [p42547 at cswks20~] > ssh-add -l > error fetching identities for protocol 1: agent refused operation > 2048 SHA256:dj02A/DHL0RKuJuMLBX14CaQ6RriT0uqY0sXqTNPoW4 > cardno:000609042340 (RSA) To see what the problem is you neeed to add these lines to ~/.gnupg/gpg-agent.conf --8<---------------cut here---------------start------------->8--- log-file /tmp/p42547-agent.log verbose debug ipc --8<---------------cut here---------------end--------------->8--- restart gpg-agent and run ssh-add-l again. > [p42547 at cswks20~] > gpg --export-secret-keys $KEYID | openpgp2ssh $KEYID > We cannot handle encrypted secret keys. Skipping! I don't know this openpgp2ssh thingie. To export an OpenPGP key as an openpgp _public_ key in ssh format use gpg -a --export-ssh-key FINGERPRINT You may need to append a '!' to the fingerprint to export a specific subkey. > gpg --export-secret-keys C5778901 gives me an asci file that then You need to add the option -a to get in in ASCII format. > complains about not being openpgp it also is missing the cardno in the The cardno is has no important information; it is merely there so that the agent can prompt you to insert the expected card. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From guru at unixarea.de Sun Jun 23 12:21:34 2019 From: guru at unixarea.de (Matthias Apitz) Date: Sun, 23 Jun 2019 10:21:34 +0000 Subject: GnuPG and SSH_AUTH_SOCK value In-Reply-To: <874l4ioydb.fsf@wheatstone.g10code.de> References: <20190621112017.GA2077@c720-r349041> <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041> <874l4ioydb.fsf@wheatstone.g10code.de> Message-ID: <20190623102134.GA1923@c720-r349041> El d?a s?bado, junio 22, 2019 a las 09:47:12a. m. +0200, Werner Koch via Gnupg-users escribi?: > That seems to be deep in the innards of KDE's X startup or Wayland or > Systemd configuration. I try to avoid all this and use the old > fashioned but easy to debug ~/.xsession I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE: $ cat ~/.xinitrc # set SSH_AUTH_SOCK # unset SSH_AGENT_PID unset SSH_AUTH_SOCK SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"; export SSH_AUTH_SOCK echo SSH_AUTH_SOCK: $SSH_AUTH_SOCK >> /tmp/xinit # setxkbmap de,us -option terminate:ctrl_alt_bksp xrandr --output default --mode 1366x768 /usr/local/bin/xbindkeys exec ck-launch-session startkde The idea is to set env var SSH_AUTH_SOCK correctly for all the xterm/urxvt processes "below" KDE. But, before the start of KDE (last line) the SSH_AUTH_SOCK is still /home/guru/.gnupg-ccid/S.gpg-agent.ssh and later when KDE is up the 'gpgconf --list-dirs agent-ssh-socket' returns /var/run/user/1001/gnupg/d.m4rfaasqebhjmgto9ddm6m7y/S.gpg-agent.ssh i.e. the env var SSH_AUTH_SOCK is set wrong and I have to reset it in any terminal. matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: ???????? ????????????! Thank you very much, Russian liberators! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jimoe at sohnen-moe.com Sun Jun 23 20:53:17 2019 From: jimoe at sohnen-moe.com (James Moe) Date: Sun, 23 Jun 2019 11:53:17 -0700 Subject: Infinite loop? Message-ID: opensuse LEAP 15.0 linux 4.12.14-lp150.12.64-default x86_64 gpg2 seems to enter an infinite loop. The system recently updated; gnupg does appear in the update log. That is all I know. I executed the command $ gpg2 --debug-all --list-keys to get a debug output. The resulting file is really large: 8.9MB. I have provided a Dropbox link to the debug file below. https://www.dropbox.com/s/xc2jtntmzhr10lg/gpg2-debug.txt?dl=0 $ gpg2 --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 This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/jmoe/.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 -- James Moe moe dot james at sohnen-moe dot com 520.743.3936 Think. From jimoe at sohnen-moe.com Mon Jun 24 00:00:40 2019 From: jimoe at sohnen-moe.com (James Moe) Date: Sun, 23 Jun 2019 15:00:40 -0700 Subject: Infinite loop? In-Reply-To: References: Message-ID: On 23/06/2019 11.53 AM, James Moe via Gnupg-users wrote: > gnupg does appear in the update log > Sigh. Typo. gnupg does NOT appear in the update log. Nor does libscrypt. The repetitive part of the log starts at line 475. -- James Moe moe dot james at sohnen-moe dot com 520.743.3936 Think. From dirk.gottschalk1980 at googlemail.com Tue Jun 25 12:53:07 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Tue, 25 Jun 2019 12:53:07 +0200 Subject: GnuPG and SSH_AUTH_SOCK value In-Reply-To: <20190623102134.GA1923@c720-r349041> References: <20190621112017.GA2077@c720-r349041> <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041> <874l4ioydb.fsf@wheatstone.g10code.de> <20190623102134.GA1923@c720-r349041> Message-ID: Hi. Am Sonntag, den 23.06.2019, 10:21 +0000 schrieb Matthias Apitz: > El d?a s?bado, junio 22, 2019 a las 09:47:12a. m. +0200, Werner Koch > via Gnupg-users escribi?: > > > That seems to be deep in the innards of KDE's X startup or Wayland > > or > > Systemd configuration. I try to avoid all this and use the old > > fashioned but easy to debug ~/.xsession > > I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE: > > $ cat ~/.xinitrc > > # set SSH_AUTH_SOCK > # > unset SSH_AGENT_PID > unset SSH_AUTH_SOCK > SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"; > export SSH_AUTH_SOCK > echo SSH_AUTH_SOCK: $SSH_AUTH_SOCK >> /tmp/xinit > # > setxkbmap de,us -option terminate:ctrl_alt_bksp > xrandr --output default --mode 1366x768 > /usr/local/bin/xbindkeys > exec ck-launch-session startkde > > The idea is to set env var SSH_AUTH_SOCK correctly for all the > xterm/urxvt > processes "below" KDE. But, before the start of KDE (last line) the > SSH_AUTH_SOCK is still > /home/guru/.gnupg-ccid/S.gpg-agent.ssh > and later when KDE is up the 'gpgconf --list-dirs agent-ssh-socket' > returns /var/run/user/1001/gnupg/d.m4rfaasqebhjmgto9ddm6m7y/S.gpg- > agent.ssh > i.e. the env var SSH_AUTH_SOCK is set wrong and I have to reset it > in any terminal. I am not running KDE, but Gnome. For my case I have a SystemD user service which starts a gpg-agent instance in background and sets the environment variables for the user on login. Originally I found this solution on the internet and I adapted it for my usecase with a few modifications. GPG doesn't start the agent becuse there is already a running instance and the authentication socket is available. SSH authentication, gpg and all other things work just fine. If this is what you want to achieve and if you want to have a look at this, tell me and I'll send you the needed Files. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From dirk.gottschalk1980 at googlemail.com Tue Jun 25 13:07:03 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Tue, 25 Jun 2019 13:07:03 +0200 Subject: GnuPG and SSH_AUTH_SOCK value In-Reply-To: <20190623102134.GA1923@c720-r349041> References: <20190621112017.GA2077@c720-r349041> <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041> <874l4ioydb.fsf@wheatstone.g10code.de> <20190623102134.GA1923@c720-r349041> Message-ID: Hi. Additionally to my previous reply: This is my $HOME/.config/systemd/user/gpg-agent.service: --- [Unit] Description=GnuPG Agent IgnoreOnIsolate=true [Service] Type=forking Environment=SSH_AUTH_SOCK=%t/gnupg/S.gpg-agent.ssh ExecStart=/usr/bin/gpg-agent --homedir %h/.gnupg --enable-ssh-support --daemon ExecStartPost=/usr/bin/systemctl --user set-environment SSH_AUTH_SOCK=${SSH_AUTH_SOCK} [Install] WantedBy=default.target --- There one could add the home directory for GnuPG, if needed. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From dirk.gottschalk1980 at googlemail.com Tue Jun 25 15:47:48 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Tue, 25 Jun 2019 15:47:48 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> Message-ID: <39af1623f803234588d1dbe5a49bdc511f9df3f1.camel@googlemail.com> Hi @ll. Am Freitag, den 14.06.2019, 10:12 +0200 schrieb Oscar Carlsson via Gnupg-users: > Hi, > I'm generally curious on your opinions on the latest new keyserver, > this > time running a new software than the normal keyservers. > They seem to have a different model which minimize the amount of > information available, to be compliant with GDPR and friends. Do you > think there are any downsides to this? Unfortunately I promised to Werner to not get political anymore about the EU and GDPR thingies. To the Server you're Mentioning: I don't think it's such a good idea to drop Signatures on keys. Validating the KEys and it's packet would mitigate many of the SKS issues. But some people and solutions rely on the signatures. Okay, running an in house keyserver might be an option for this situations. Also the centralized Approach is a no go in my opinion. Reading this thread, I feel like I've done a time travel, back to the times where people distributed their keys over the usenet due to the lack of keyserver dunctionality. Keyservers like the desribed one is less than useless in my opinion. Even removing the ability to search for keys by UID is a thing I don't like. But that's the GDPR panic. Yes, I know, no politics from the angry guy. ^^ So, it's pretty hot here. Werner must have turned on the Heater. I'll be quite now. :D Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From look at my.amazin.horse Tue Jun 25 16:30:49 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 25 Jun 2019 16:30:49 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <39af1623f803234588d1dbe5a49bdc511f9df3f1.camel@googlemail.com> References: <39af1623f803234588d1dbe5a49bdc511f9df3f1.camel@googlemail.com> <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> Message-ID: <3NTU2ZDNFR80P.3CN4RPAJE8LVZ@my.amazin.horse> > Hi @ll. Hi Dirk, thanks for your thoughts! > I don't think it's such a good idea to drop Signatures on keys. As mentioned in our FAQ, the reason we don't support those is that with the SKS model, anyone can attach arbitrary data to others' keys. It's hard to overstate how problematic that is. I can just add a megabyte or fifty of data to your key. There are solutions that still allow for some of the TPS-based use cases, but until there is at least some agreement on how to proceed, we decided against supporting them. Free distribution of arbitrary TPSes is quite simply not a viable model for any keyserver. The discussion shouldn't be about liking or disliking them, it should be about what alternatives could be. I see from your signing policy that you do a caff-style workflow. Have you considered the option to have keys cross-sign third party signatures for publication? It's a very slight switch in tooling if we assume a caff workflow, but that way each key remains in control of the public version of itself. > Also the centralized Approach is a no go in my opinion. The open federation model of SKS means all email addresses are enumeratable. That's a privacy no-go in my opinion, which people have gotten surprisingly used to in this community. I can imagine a closed federation model, where we have a handful of operators but still don't need to have personal information of our users in the open. Maybe we'll move in that direction once the dust has settled a bit. The keyserver ecosystem has been stagnant in more than a decade, so.. one step after another. > Even removing the ability to search for keys by UID is a thing I don't > like. Why not? Do you think "find all Dirks on the keyserver" is a valid use case that should be supported? Cheers - V From dirk.gottschalk1980 at googlemail.com Tue Jun 25 17:41:12 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Tue, 25 Jun 2019 17:41:12 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <3NTU2ZDNFR80P.3CN4RPAJE8LVZ@my.amazin.horse> References: <39af1623f803234588d1dbe5a49bdc511f9df3f1.camel@googlemail.com> <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <3NTU2ZDNFR80P.3CN4RPAJE8LVZ@my.amazin.horse> Message-ID: <462b9f638e0549e5fbe1866e35737110212a4be0.camel@googlemail.com> Am Dienstag, den 25.06.2019, 16:30 +0200 schrieb Vincent Breitmoser: > > Hi @ll. > Hi Dirk, > thanks for your thoughts! > > I don't think it's such a good idea to drop Signatures on keys. > As mentioned in our FAQ, the reason we don't support those is that > with the SKS model, anyone can attach arbitrary data to others' > keys. It's hard to overstate how problematic that is. I can just add > a megabyte or fifty of data to your key. The Upload should be restricted to the key owner in some way. That would mitigate this Problem and it should help against a key mess up I made a short while ago. > There are solutions that still allow for some of the TPS-based use > cases, but until there is at least some agreement on how to proceed, > we decided against supporting them. TPS? Okay, it's warm and I don't get this. But yes, a minimal agreement about the procedures would at least be neccessary. > Free distribution of arbitrary TPSes is quite simply not a viable > model for any keyserver. The discussion shouldn't be about liking or > disliking them, it should be about what alternatives could be. That's right. As told, SKS is far away from perfect and your solution goes the right way. Nothing prevents the implementation of, let's say key signatures in further versions or different versions to be used in environments on an in house server. > I see from your signing policy that you do a caff-style workflow. > Have you considered the option to have keys cross-sign third party > signatures for publication? It's a very slight switch in tooling if > we assume a caff workflow, but that way each key remains in control > of the public version of itself. I didn't consider it until you mentioned ist. A good idea, thanks. > > Also the centralized Approach is a no go in my opinion. > The open federation model of SKS means all email addresses are > enumeratable. That's a privacy no-go in my opinion, which people have > gotten surprisingly used to in this community. Isn't verifying the origination of an Email, including the address, one of the PGP approaches? Theres simply one point: "If you do not want your email to be public, don't upload your key to a server." If I didn't want my address to be known by others, I shouldn't post to an open ML. Same thing in my opinion. > I can imagine a closed federation model, where we have a handful of > operators but still don't need to have personal information of our > users in the open. In my opinion, the UID is essential for the Keys, except of M2M Usage. > Maybe we'll move in that direction once the dust has settled a bit. > The keyserver ecosystem has been stagnant in more than a decade, so.. > one step after another. Yes, the key servers (SKS) have come of age and some things weren't "on the radar screen" of it's developers for various reasons. > > Even removing the ability to search for keys by UID is a thing I > > don't like. > Why not? Do you think "find all Dirks on the keyserver" is a valid > use case that should be supported? No. But if I want to sent you an email and want to encrypt it on a machine with an empty keystore, shouldn't I be able to fetch your key by Address? It could be realized by exact match of the email address instead of spitting everything out that comes near to the requested string. Just my 2 cents and I am open to discuss benefits and downsides. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From look at my.amazin.horse Tue Jun 25 17:54:00 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 25 Jun 2019 17:54:00 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <462b9f638e0549e5fbe1866e35737110212a4be0.camel@googlemail.com> References: <462b9f638e0549e5fbe1866e35737110212a4be0.camel@googlemail.com> <39af1623f803234588d1dbe5a49bdc511f9df3f1.camel@googlemail.com> <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <3NTU2ZDNFR80P.3CN4RPAJE8LVZ@my.amazin.horse> Message-ID: <31CSGY53YF09J.1Z2I4F1N1HOUR@my.amazin.horse> > The Upload should be restricted to the key owner in some way. We restrict upload of user ids to the owner of the user id, identified by email verification. Non-identity data (subkeys, revocations, ...) can be freely distributed, but only with a verified self-signature. Is there any other mechanism you can come up with to allow upload by the owner of some key data or email addresses, but not others? > I didn't consider it until you mentioned ist. A good idea, thanks. Great! I've been getting generally positive feedback about this idea, perhaps we should look into that more seriously. > Theres simply one point: "If you do not want your email to be public, don't > upload your key to a server." What if I upload your key to a server though? Keep in mind this is not just a "nice to have", it is a legal requirement. > In my opinion, the UID is essential for the Keys, except of M2M Usage. > (...) > No. But if I want to sent you an email and want to encrypt it on a > machine with an empty keystore, shouldn't I be able to fetch your key > by Address? Of course! And we do support that, given consent from the owner of an address. Without that, only non-identity data (still enough for M2M) is distributed. > It could be realized by exact match This is exactly what we do. :) - V From dkg at fifthhorseman.net Tue Jun 25 17:37:07 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 Jun 2019 11:37:07 -0400 Subject: Change socketdir from ~/.gnupg to /run/user/ In-Reply-To: References: <20190617135821.GA1297@osboxes> Message-ID: <875zotwuak.fsf@fifthhorseman.net> On Tue 2019-06-18 04:03:45 -0400, vijai kumar via Gnupg-users wrote: > I am using gpg inside a docker container. By default, there is no > /run/user/ in the container so gpg defaults to ~/.gnupg as socket > directory. Is there a provision to change the socket directory later? > Now, I would like to create /run/user/$(id -u)/gnupg and use this as > the default socket directory. Is there a way to kill the existing agent > and relaunch it with the new socket directory? Ideally, you'd ensure that /run/user/$(id -u) is created during the session launch within the docker container, so that it's present from the beginning. If you already have an agent running from before /run/user/$(id -u) exists, you can kill it with a SIGTERM. A new agent will be launched appropriately using /run/user/$(id -u) automatically when it is needed. all the best, --dkg From dkg at fifthhorseman.net Tue Jun 25 17:34:16 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 Jun 2019 11:34:16 -0400 Subject: GnuPG on debian [was: Re: GPG/YubiKey/CentOS7] In-Reply-To: <20190622074144.z6nm54f2likjbhs6@gruenfink> References: <6b4009746ab846fba1586d61a706f3db@SLCMBXW04VP.pacificorp.us> <20190622074144.z6nm54f2likjbhs6@gruenfink> Message-ID: <878stpwufb.fsf@fifthhorseman.net> On Sat 2019-06-22 09:41:46 +0200, Wolfgang Traylor via Gnupg-users wrote: > On Debian: Prepare GnuPG > ======================== > > SSH support is not given by GnuPG 1. The `gpg` executable must be version 2.0 or higher. > On Debian system, `gpg` is still the old version by default. We change that globally. this is pretty out of date, debian has shipped modern GnuPG as "gpg" since the current stable release (about two years ago now). Please update your documentation :) all the best, --dkg From dkg at fifthhorseman.net Tue Jun 25 17:57:41 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 Jun 2019 11:57:41 -0400 Subject: missing root certificate, SMIME spanish government In-Reply-To: <87imtpvcif.fsf@mat.ucm.es> References: <87v9xqsp0w.fsf@mat.ucm.es> <20190601082804.bvub3dr5tnhyl5ks@gruenfink> <87imtpvcif.fsf@mat.ucm.es> Message-ID: <87zhm5veru.fsf@fifthhorseman.net> On Sat 2019-06-01 12:14:00 +0200, Uwe Brauer wrote: > In any case I finally solveed the issue by just importing all available > cer into gpgsm and it worked, by mistake was to assume that gpgsm uses > the ones which are installed system wide. I agree that gpgsm integration with the system keyring is lacking. Please see https://bugs.debian.org/888025 for discussion on how that might be improved. I'd love to hear any feedback or thoughts there. (and would be even happier to receive patches i could review). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Jun 25 17:12:43 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 Jun 2019 11:12:43 -0400 Subject: gpg-agent systemd user service [was: Re: GnuPG and SSH_AUTH_SOCK value] In-Reply-To: References: <20190621112017.GA2077@c720-r349041> <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041> <874l4ioydb.fsf@wheatstone.g10code.de> <20190623102134.GA1923@c720-r349041> Message-ID: <87ef3hwvf8.fsf@fifthhorseman.net> On Tue 2019-06-25 13:07:03 +0200, Dirk Gottschalk via Gnupg-users wrote: > This is my $HOME/.config/systemd/user/gpg-agent.service: If you're using gpg-agent as a systemd user service, please use the systemd unit files (.service and .socket definitions) that ship with GnuPG itself. There are a number of subtle (and not-so-subtle) problems with your proposed gpg-agent systemd user service definition. In contrast, the upstream one has been fairly widely tested. If the standard upstream service doesn't work for you for some reason, please explain why it doesn't work for you, and report it as a bug so that we can fix it for everyone. While you're of course free to use custom variants like this for yourself, please don't recommend that other people use them, because it makes it much more difficult for the GnuPG project to support other users. All the best, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Jun 25 17:54:07 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 Jun 2019 11:54:07 -0400 Subject: Adding notations with quick commands In-Reply-To: <45c17b27-132b-aafe-e89e-e5c8c51903f6@metacode.biz> References: <20190609121608.GA5982@pc21.mareichelt.com> <45c17b27-132b-aafe-e89e-e5c8c51903f6@metacode.biz> Message-ID: <8736jxwti8.fsf@fifthhorseman.net> On Sun 2019-06-09 19:17:10 +0200, Wiktor Kwapisiewicz via Gnupg-users wrote: > Hi Markus, > > On 09.06.2019 14:16, Markus Reichelt wrote: >>> in a similar fashion to what --quick-* commands already do for other actions >>> (e.g. --quick-add-uid). >> >> --set-notation maybe? > > Yes, but as far as I understand --set-notation is only a modifier that > needs to be used with another command (e.g. --quick-sign-key). > > I tried using it with my own fingerprint twice but it didn't succeed: > > $ gpg -u F470E50DCB1AD5F1E64E08644A63613A4D6E4094 --set-notation > test at example.com=zzzz --quick-sign-key > F470E50DCB1AD5F1E64E08644A63613A4D6E4094 > "Test McTestington " was already signed by key > 4A63613A4D6E4094 > Nothing to sign with key 4A63613A4D6E4094 > gpg: Key not changed so no update needed. I don't know of a way to do this automatically if there is already a certification from the current issuer over the OpenPGP User ID in question, unless the old certification is local (non-exportable), and the new one is not. in that special case, gpg seems fine with issuing the new certification (and will respect --cert-notation or --set-notation when doing so). I've opened https://dev.gnupg.org/T4584 to track this bug. Please follow up over there. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Jun 25 17:30:35 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 Jun 2019 11:30:35 -0400 Subject: Infinite loop? In-Reply-To: References: Message-ID: <87blylwulg.fsf@fifthhorseman.net> On Sun 2019-06-23 15:00:40 -0700, James Moe via Gnupg-users wrote: > On 23/06/2019 11.53 AM, James Moe via Gnupg-users wrote: > >> gnupg does appear in the update log >> > Sigh. Typo. > gnupg does NOT appear in the update log. Nor does libscrypt. Without having access to your pubring.gpg, it's hard to say what is triggering this loop. I also note that gpg version 2.2.5 is fairly old -- is it possible to try to upgrade to a newer version? > The repetitive part of the log starts at line 475. The repetitions at 475 actually end at 8144, and different things appear to be happening in that debug log up until you sent it an interrupt to cancel. Is it possible that your pubring.gpg is corrupt? Can you replicate this with a minimal GNUPGHOME? Can you try migrating from pubring.gpg to pubring.kbx and see if you still have the same problem? A script for doing that migration is here if you want to try: https://salsa.debian.org/debian/gnupg2/blob/debian/master/debian/migrate-pubring-from-classic-gpg (you might want to back up your ~/.gnupg/ before trying) All the best, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dirk.gottschalk1980 at googlemail.com Tue Jun 25 18:15:09 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Tue, 25 Jun 2019 18:15:09 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <31CSGY53YF09J.1Z2I4F1N1HOUR@my.amazin.horse> References: <462b9f638e0549e5fbe1866e35737110212a4be0.camel@googlemail.com> <39af1623f803234588d1dbe5a49bdc511f9df3f1.camel@googlemail.com> <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <3NTU2ZDNFR80P.3CN4RPAJE8LVZ@my.amazin.horse> <31CSGY53YF09J.1Z2I4F1N1HOUR@my.amazin.horse> Message-ID: <2c3af41b5b76d83097b4de3c8f0c086124eb3631.camel@googlemail.com> Hi. Am Dienstag, den 25.06.2019, 17:54 +0200 schrieb Vincent Breitmoser: > > The Upload should be restricted to the key owner in some way. > We restrict upload of user ids to the owner of the user id, > identified by email verification. Non-identity data (subkeys, > revocations, ...) can be freely distributed, but only with a verified > self-signature. That's what I had in mind. > Is there any other mechanism you can come up with to allow upload by > the owner of some key data or email addresses, but not others? Additionally some kind of authentication mechanism would be required to avoid fake uploads like just a faked sender address. I implicated this wordless. Other mechanisms could be possible but I don't have any special thoughts regarding this at the moment. > > I didn't consider it until you mentioned ist. A good idea, thanks. > Great! I've been getting generally positive feedback about this idea, > perhaps we should look into that more seriously. Yes, I agree. > > Theres simply one point: "If you do not want your email to be > > public, don't upload your key to a server." > What if I upload your key to a server though? Keep in mind this is > not just a "nice to have", it is a legal requirement. This would not be poissible with an authentication mechanism. See above. Only the owner should be able to modify his key or make ammendements. Probably except for revocations, in somne cases. > > In my opinion, the UID is essential for the Keys, except of M2M > > Usage. > > (...) > > No. But if I want to sent you an email and want to encrypt it on a > > machine with an empty keystore, shouldn't I be able to fetch your > > key > > by Address? > Of course! And we do support that, given consent from the owner of an > address. Without that, only non-identity data (still enough for M2M) > is distributed. M2M keys don't need a UID at all. I made such keys f?r my automatic backups and for some of the telematics solutions I work on. We use them only to encrypt, sign and send tachograph data files which are sent to our customers by email, for example. > > It could be realized by exact match > This is exactly what we do. :) So you support key search, this is a good point. And it ind of changes my opinion about the new servers. I didn't have the time to dig deeper into this new server and my opinion is based upon the things I read on the list. So this discussion is really helpful. Just the point of a centralized server is a thing that is not good in my opinion, but there should and will be a way to implement a distributed system into this project. A synchronizatio?n mechanism has to be well overthought, that's one point, but technically there are some ways to implement a secure and stable mechanism to achieve distribution. This is a point which should be considered. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From dirk.gottschalk1980 at googlemail.com Tue Jun 25 18:44:38 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Tue, 25 Jun 2019 18:44:38 +0200 Subject: gpg-agent systemd user service [was: Re: GnuPG and SSH_AUTH_SOCK value] In-Reply-To: <87ef3hwvf8.fsf@fifthhorseman.net> References: <20190621112017.GA2077@c720-r349041> <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041> <874l4ioydb.fsf@wheatstone.g10code.de> <20190623102134.GA1923@c720-r349041> <87ef3hwvf8.fsf@fifthhorseman.net> Message-ID: <506c1ad54db5999a4adf302aadc8613db7709620.camel@googlemail.com> Hello. Am Dienstag, den 25.06.2019, 11:12 -0400 schrieb Daniel Kahn Gillmor: > On Tue 2019-06-25 13:07:03 +0200, Dirk Gottschalk via Gnupg-users > wrote: > > This is my $HOME/.config/systemd/user/gpg-agent.service: > If you're using gpg-agent as a systemd user service, please use the > systemd unit files (.service and .socket definitions) that ship with > GnuPG itself. Sorry, I didn't even know there are such files. I just used the packages from Fedora and didn't look deeper into the packages. Thanks for your Comment. > If the standard upstream service doesn't work for you for some > reason, please explain why it doesn't work for you, and report it as > a bug so that we can fix it for everyone. I'll test them this evening, thanks againm. > While you're of course free to use custom variants like this for > yourself, please don't recommend that other people use them, because > it makes it much more difficult for the GnuPG project to support > other users. I didn't know about them and have not seen thgem in the source tree. Pure blindness I think. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From dkg at fifthhorseman.net Tue Jun 25 18:46:11 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 Jun 2019 12:46:11 -0400 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <462b9f638e0549e5fbe1866e35737110212a4be0.camel@googlemail.com> References: <39af1623f803234588d1dbe5a49bdc511f9df3f1.camel@googlemail.com> <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <3NTU2ZDNFR80P.3CN4RPAJE8LVZ@my.amazin.horse> <462b9f638e0549e5fbe1866e35737110212a4be0.camel@googlemail.com> Message-ID: <87tvcdvcj0.fsf@fifthhorseman.net> On Tue 2019-06-25 17:41:12 +0200, Dirk Gottschalk via Gnupg-users wrote: > Am Dienstag, den 25.06.2019, 16:30 +0200 schrieb Vincent Breitmoser: >> Have you considered the option to have keys cross-sign third party >> signatures for publication? It's a very slight switch in tooling if >> we assume a caff workflow, but that way each key remains in control >> of the public version of itself. > > I didn't consider it until you mentioned ist. A good idea, thanks. One concrete proposal for a mechanism for how to do this at the protocol level is "First-party-attested Third-party Certifications", documented here: https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-03#section-10 To make this feasible requires some work on the client side. The protocol implementation is likely to be the easy part. The hard part is the UI/UX work to make this something that a normal human can understand and do without too much pain. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jimoe at sohnen-moe.com Tue Jun 25 21:02:13 2019 From: jimoe at sohnen-moe.com (James Moe) Date: Tue, 25 Jun 2019 12:02:13 -0700 Subject: Infinite loop? In-Reply-To: <87blylwulg.fsf@fifthhorseman.net> References: <87blylwulg.fsf@fifthhorseman.net> Message-ID: On 25/06/2019 8.30 AM, Daniel Kahn Gillmor wrote: > Is it possible that your pubring.gpg is corrupt? > As it happens, yes. The size of pubring.gpg was 20MB; the backup copy was 1.3MB. After restoring from backup, gpg2 performs normally. Thank you. -- James Moe moe dot james at sohnen-moe dot com 520.743.3936 Think. From dkg at fifthhorseman.net Wed Jun 26 00:47:11 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 Jun 2019 18:47:11 -0400 Subject: Infinite loop? In-Reply-To: References: <87blylwulg.fsf@fifthhorseman.net> Message-ID: <871rzhuvtc.fsf@fifthhorseman.net> On Tue 2019-06-25 12:02:13 -0700, James Moe via Gnupg-users wrote: > On 25/06/2019 8.30 AM, Daniel Kahn Gillmor wrote: > >> Is it possible that your pubring.gpg is corrupt? > > As it happens, yes. > The size of pubring.gpg was 20MB; the backup copy was 1.3MB. After > restoring from backup, gpg2 performs normally. Interesting! my pubring.kbx is 147MiB, but GnuPG still should not run forever when doing --list-keys. It takes 17s to complete the listing of my pubring.kbx, as measured by "time gpg --list-keys > /dev/null" gpg should not take forever to list a 20MB keyring. If you still have a copy of the corrupt 20M pubring.gpg, it might be interesting to see it as an example, because it sounds like it's tickling a bug. however, sharing your keyring might be sensitive, and 20MB certainly won't fit in a message on this mailing list. If you are willing to share it privately so this can be tracked down, feel free to reply to me privately and we can figure out the details. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gnupg-users at spodhuis.org Wed Jun 26 05:03:18 2019 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Tue, 25 Jun 2019 23:03:18 -0400 Subject: Infinite loop? In-Reply-To: <871rzhuvtc.fsf@fifthhorseman.net> References: <87blylwulg.fsf@fifthhorseman.net> <871rzhuvtc.fsf@fifthhorseman.net> Message-ID: <20190626030317.GA26120@breadbox.private.spodhuis.org> On 2019-06-25 at 18:47 -0400, Daniel Kahn Gillmor via Gnupg-users wrote: > Interesting! my pubring.kbx is 147MiB, but GnuPG still should not run > forever when doing --list-keys. It takes 17s to complete the listing of > my pubring.kbx, as measured by "time gpg --list-keys > /dev/null" With GnuPG 2.2.16 : % ls -ldh ~/.gnupg/pubring.kbx -rw-r--r-- 1 pdp pdp 241M Jun 22 22:16 /home/pdp/.gnupg/pubring.kbx % time gpg --list-keys >/dev/null [...] gpg --list-keys > /dev/null 1473.99s user 1965.72s system 99% cpu 57:19.85 total % kbxutil --stats .gnupg/pubring.kbx Total number of blobs: 5640 header: 1 empty: 0 openpgp: 5638 x509: 1 non flagged: 5638 secret flagged: 0 ephemeral flagged: 1 This is an "Intel(R) Atom(TM) CPU D2500 @ 1.86GHz" and is where I've long had my high-security keys. One bright side to this box and its speed: it's immune to speculative prediction attacks. None of that newfangled nonsense. ;) I've long been resigned to this being normal. An unthinking import of a fuller keyring (probably this one) to my recent new work laptop (Thinkpad X1 Carbon, running Ubuntu) led to confusion as I re-acclimated to a Linux desktop after years of macOS usage, because core parts of system preferences appeared to just hang and do nothing. Until I finally realized the problem and nuked the keyring down to a dozen keys which most mattered here. I hadn't realize that my GnuPG keyring was being exposed in my view of the preferences. In fact, I got so used to seahorse just dying that I adjusted my login scripts to ignore it and fire up my own ssh-agent so that I wouldn't lose the ability to log into other machines. I made that conditional upon the socket being dead and grumpily chalked it up to Linux flakiness, but I see now that this hasn't been getting triggered recently. The X1 Carbon is 8 claimed cores of "Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz" and 16GiB RAM. It was definitely not happy at a keyring which lets me comfortably verify software releases from signers in the strong set. > If you still have a copy of the corrupt 20M pubring.gpg, it might be > interesting to see it as an example, because it sounds like it's > tickling a bug. If you're interested, I can share mine; there are no "secret" keys in it and I'll trust you not to leak the communications graph of which software I care about verifying :) or the public signatures from the strong set showing where I've been over the years or the local signatures for "yeah, I grabbed these fingerprints from a web-page, I'll trust them locally but won't attest to them publicly". -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 996 bytes Desc: Digital signature URL: From dkg at fifthhorseman.net Wed Jun 26 07:34:56 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Jun 2019 01:34:56 -0400 Subject: Infinite loop? In-Reply-To: <20190626030317.GA26120@breadbox.private.spodhuis.org> References: <87blylwulg.fsf@fifthhorseman.net> <871rzhuvtc.fsf@fifthhorseman.net> <20190626030317.GA26120@breadbox.private.spodhuis.org> Message-ID: <87ef3gucxr.fsf@fifthhorseman.net> On Tue 2019-06-25 23:03:18 -0400, Phil Pennock wrote: > With GnuPG 2.2.16 : > > % ls -ldh ~/.gnupg/pubring.kbx > -rw-r--r-- 1 pdp pdp 241M Jun 22 22:16 /home/pdp/.gnupg/pubring.kbx > % time gpg --list-keys >/dev/null > [...] > gpg --list-keys > /dev/null 1473.99s user 1965.72s system 99% cpu 57:19.85 total > % kbxutil --stats .gnupg/pubring.kbx > Total number of blobs: 5640 > header: 1 > empty: 0 > openpgp: 5638 > x509: 1 > non flagged: 5638 > secret flagged: 0 > ephemeral flagged: 1 > > This is an "Intel(R) Atom(TM) CPU D2500 @ 1.86GHz" and is where I've > long had my high-security keys. One bright side to this box and its > speed: it's immune to speculative prediction attacks. None of that > newfangled nonsense. ;) i'm glad you have a sense of humor about it, but this sounds unacceptably slow to me. --list-keys isn't even doing any cryptographic processing, right? > I've long been resigned to this being normal. the timing you show above suggests that --list-keys operates at ~100 keys per minute, or not even 2 keys per second. And why on earth is so much time spent in the kernel? for my own run, the breakdown is: real 0m17.555s user 0m17.367s sys 0m0.184s But yours appears to have > 50% of its time spent in "sys". Can you use strace -T or some other profiler to see what system calls it's making that makes it spend so much time in the kernel? > In fact, I got so used to seahorse just dying that I adjusted my login > scripts to ignore it and fire up my own ssh-agent so that I wouldn't > lose the ability to log into other machines. I made that conditional > upon the socket being dead and grumpily chalked it up to Linux > flakiness, but I see now that this hasn't been getting triggered > recently. > > The X1 Carbon is 8 claimed cores of "Intel(R) Core(TM) i7-8650U CPU @ > 1.90GHz" and 16GiB RAM. It was definitely not happy at a keyring which > lets me comfortably verify software releases from signers in the strong > set. numbers like 5K keys and 241MiB are not large for a machine of this caliber. my own kbxutil --stats looks like: Total number of blobs: 4166 header: 1 empty: 0 openpgp: 3787 x509: 378 non flagged: 4165 secret flagged: 0 ephemeral flagged: 0 If you import your larger keyring on the X1 Carbon, what is the output of "time gpg --list-keys > /dev/null" there? > If you're interested, I can share mine; there are no "secret" keys in it > and I'll trust you not to leak the communications graph of which > software I care about verifying :) or the public signatures from the > strong set showing where I've been over the years or the local > signatures for "yeah, I grabbed these fingerprints from a web-page, I'll > trust them locally but won't attest to them publicly". If the issue is just a large keyring, i can generate that myself pretty easily, thanks. I was concerned by the OP that there was an acual infinite loop somewhere. But if the run is just taking a long time because of unoptimized code, we should try to address that as a separate issue. --dkg ps fwiw, i think even 17s is too long for my own 4K keys, esp. with a hot fileysystem cache. that's still only ~220 per second, but it's managable, and i've had enough other things i want to get fixed in GnuPG that i haven't dug in too deeply to see where the problem is or how it could be sped up. But it's nothing near the order of magnitude that you're describing. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From guru at unixarea.de Wed Jun 26 07:47:11 2019 From: guru at unixarea.de (Matthias Apitz) Date: Wed, 26 Jun 2019 07:47:11 +0200 Subject: gpg-agent systemd user service [was: Re: GnuPG and SSH_AUTH_SOCK value] In-Reply-To: <87ef3hwvf8.fsf@fifthhorseman.net> References: <20190621112017.GA2077@c720-r349041> <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041> <874l4ioydb.fsf@wheatstone.g10code.de> <20190623102134.GA1923@c720-r349041> <87ef3hwvf8.fsf@fifthhorseman.net> Message-ID: <20190626054711.GA3721@c720-r342378> El d?a martes, junio 25, 2019 a las 11:12:43a. m. -0400, Daniel Kahn Gillmor escribi?: > On Tue 2019-06-25 13:07:03 +0200, Dirk Gottschalk via Gnupg-users wrote: > > This is my $HOME/.config/systemd/user/gpg-agent.service: > > If you're using gpg-agent as a systemd user service, please use the > systemd unit files (.service and .socket definitions) that ship with > GnuPG itself. > > ... Thanks for all the helping hands and hints about systemd(8), but FreeBSD normally does not run/use this. AFAIK, there is not even an official port of it in the FreeBSD's ports collection. matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: ???????? ????????????! Thank you very much, Russian liberators! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wk at gnupg.org Wed Jun 26 08:13:51 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Jun 2019 08:13:51 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <31CSGY53YF09J.1Z2I4F1N1HOUR@my.amazin.horse> (Vincent Breitmoser via Gnupg-users's message of "Tue, 25 Jun 2019 17:54:00 +0200") References: <462b9f638e0549e5fbe1866e35737110212a4be0.camel@googlemail.com> <39af1623f803234588d1dbe5a49bdc511f9df3f1.camel@googlemail.com> <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <3NTU2ZDNFR80P.3CN4RPAJE8LVZ@my.amazin.horse> <31CSGY53YF09J.1Z2I4F1N1HOUR@my.amazin.horse> Message-ID: <87ftnwnaao.fsf@wheatstone.g10code.de> On Tue, 25 Jun 2019 17:54, gnupg-users at gnupg.org said: >> Theres simply one point: "If you do not want your email to be public, don't >> upload your key to a server." > > What if I upload your key to a server though? Keep in mind this is not just > a "nice to have", it is a legal requirement. For whom, the holder of the mail address, the uploader, or the responsible person for thge keyserver? Please cite the section from the GDPR and the, say, German implementation along with relevant commentary to show why this is a legal requirement. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Wed Jun 26 10:19:38 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 26 Jun 2019 10:19:38 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <87ftnwnaao.fsf@wheatstone.g10code.de> References: <462b9f638e0549e5fbe1866e35737110212a4be0.camel@googlemail.com> <39af1623f803234588d1dbe5a49bdc511f9df3f1.camel@googlemail.com> <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <3NTU2ZDNFR80P.3CN4RPAJE8LVZ@my.amazin.horse> <31CSGY53YF09J.1Z2I4F1N1HOUR@my.amazin.horse> <87ftnwnaao.fsf@wheatstone.g10code.de> Message-ID: Werner Koch via Gnupg-users wrote: > On Tue, 25 Jun 2019 17:54, gnupg-users at gnupg.org said: > > >> Theres simply one point: "If you do not want your email to be public, don't > >> upload your key to a server." > > > > What if I upload your key to a server though? Keep in mind this is not just > > a "nice to have", it is a legal requirement. > > For whom, the holder of the mail address, the uploader, or the > responsible person for thge keyserver? > > Please cite the section from the GDPR and the, say, German > implementation along with relevant commentary to show why this is a > legal requirement. Maybe article 17 makes it clear that at least people have the right that their data has to been deleted, which is with the old model not possible. https://gdpr-info.eu/art-17-gdpr/ Regards Stefan From sac at 300baud.de Wed Jun 26 10:46:03 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 26 Jun 2019 10:46:03 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? References: <462b9f638e0549e5fbe1866e35737110212a4be0.camel@googlemail.com> <39af1623f803234588d1dbe5a49bdc511f9df3f1.camel@googlemail.com> <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <3NTU2ZDNFR80P.3CN4RPAJE8LVZ@my.amazin.horse> <31CSGY53YF09J.1Z2I4F1N1HOUR@my.amazin.horse> <87ftnwnaao.fsf@wheatstone.g10code.de> Message-ID: Stefan Claas via Gnupg-users wrote: > Werner Koch via Gnupg-users wrote: > > > On Tue, 25 Jun 2019 17:54, gnupg-users at gnupg.org said: > > > > >> Theres simply one point: "If you do not want your email to be public, > > >> don't upload your key to a server." > > > > > > What if I upload your key to a server though? Keep in mind this is not > > > just a "nice to have", it is a legal requirement. > > > > For whom, the holder of the mail address, the uploader, or the > > responsible person for thge keyserver? > > > > Please cite the section from the GDPR and the, say, German > > implementation along with relevant commentary to show why this is a > > legal requirement. > > Maybe article 17 makes it clear that at least people have the right > that their data has to been deleted, which is with the old model not > possible. > > https://gdpr-info.eu/art-17-gdpr/ And then we should take a closer look at section d): the personal data have been unlawfully processed; Maybe worth further discussions. If someone trollwot my pub key and it has illegal content then it would be IMHO unlawful. Now I think if I am not giving my consent to upload and process my pub key it would be also unlawful, right? Regards Stefan From sylvain.besencon at unifr.ch Wed Jun 26 11:47:21 2019 From: sylvain.besencon at unifr.ch (BESENCON Sylvain) Date: Wed, 26 Jun 2019 09:47:21 +0000 Subject: anthropological research on OpenPGP Message-ID: <51684e0bfe2d4e998e41dc8c8d04a30a@svw-exmb2.unifr.ch> Dear Daniel Kahn Gillmor, My name is Sylvain Besen?on, I am an anthropologist from the university of Fribourg, Switzerland, and I am doing a research for my PhD on the maintenance work of OpenPGP implementations, not from a technical point of view but rather from a socio-historical perspective. My objectives are, on the one hand, to collect information about the history of OpenPGP (from the very early days up to now), and on the second hand, to document the maintenance work that is done to keep the protocol and its implementations secure. However, my interest for OpenPGP goes beyond my sole academic papers: I love crypto, I love open source and I love easy-to-use privacy enhancing technologies. This is why I would love to be able to modestly contribute to this by bringing what I can do, namely socio-anthropological analyses to document the community effort to securely deploy such technologies. I have seen that you are quite active on the mailing list of GnuPG-users which is where I had your email address, and I was wondering if you would agree to help me in my research by answering a few questions during an interview (per video con, phone call or merely email). I also saw that you participate at the IETF and I was wondering if you will go to Montreal for the 150th IETF meeting in a few weeks? I might also be able to come and that would be fantastic to meet you in person there. I look forward to hearing from you, Kind regards, Sylvain -- Sylvain Besen?on ?? Assistant dipl?m? Unit? anthropologie sociale D?partement des sciences sociales Universit? de Fribourg Bld. de P?rolles 90, CH-1700 Fribourg PER21 - Bureau G320 +41 26 300 78 46 PGP: 9DDA 48E2 24FC A040 6B3A Blog: https://blog.unifr.ch/cva Platform for Experimental and Collaborative Ethnography: https://cva.unifr.ch -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x48E224FCA0406B3A.asc Type: application/pgp-keys Size: 4658 bytes Desc: 0x48E224FCA0406B3A.asc URL: From sylvain.besencon at unifr.ch Wed Jun 26 13:49:39 2019 From: sylvain.besencon at unifr.ch (BESENCON Sylvain) Date: Wed, 26 Jun 2019 11:49:39 +0000 Subject: anthropological research on OpenPGP References: <51684e0bfe2d4e998e41dc8c8d04a30a@svw-exmb2.unifr.ch> Message-ID: Oh no!! I'm terrible, I have just discovered that I have sent this mail to the whole mailing list. Sorry to all of you for the inconvenience... However, this might also be an opportunity for me to send my call to the whole community. Le 26.06.19 ? 11:47, BESENCON Sylvain via Gnupg-users a ?crit?: > My name is Sylvain Besen?on, I am an anthropologist from the university > of Fribourg, Switzerland, and I am doing a research for my PhD on the > maintenance work of OpenPGP implementations, not from a technical point > of view but rather from a socio-historical perspective. My objectives > are, on the one hand, to collect information about the history of > OpenPGP (from the very early days up to now), and on the second hand, to > document the maintenance work that is done to keep the protocol and its > implementations secure. However, my interest for OpenPGP goes beyond my > sole academic papers: I love crypto, I love open source and I love > easy-to-use privacy enhancing technologies. This is why I would love to > be able to modestly contribute to this by bringing what I can do, namely > socio-anthropological analyses to document the community effort to > securely deploy such technologies. Anyone interested to help me doing this research are of course more than welcome! I would be definitely very happy if you would have time to share your experience and ideas with me, specially on the history of OpenPGP, the maintenance work that you do to maintain it secure, and some important controversies. Please, write me in private so that we do not disturb more the mailing list!... Again, sorry for having sent this email to everybody... -- Sylvain Besen?on ?? Assistant dipl?m? Unit? anthropologie sociale D?partement des sciences sociales Universit? de Fribourg Bld. de P?rolles 90, CH-1700 Fribourg PER21 - Bureau G320 +41 26 300 78 46 PGP: 9DDA 48E2 24FC A040 6B3A Blog: https://blog.unifr.ch/cva Platform for Experimental and Collaborative Ethnography: https://cva.unifr.ch From dkg at fifthhorseman.net Wed Jun 26 13:03:19 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Jun 2019 07:03:19 -0400 Subject: gpg-agent systemd user service [was: Re: GnuPG and SSH_AUTH_SOCK value] In-Reply-To: <20190626054711.GA3721@c720-r342378> References: <20190621112017.GA2077@c720-r349041> <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041> <874l4ioydb.fsf@wheatstone.g10code.de> <20190623102134.GA1923@c720-r349041> <87ef3hwvf8.fsf@fifthhorseman.net> <20190626054711.GA3721@c720-r342378> Message-ID: <875zostxqg.fsf@fifthhorseman.net> On Wed 2019-06-26 07:47:11 +0200, Matthias Apitz wrote: > Thanks for all the helping hands and hints about systemd(8), but FreeBSD > normally does not run/use this. AFAIK, there is not even an official > port of it in the FreeBSD's ports collection. That's correct, systemd depends on the Linux kernel, and does not run on FreeBSD. Sorry that the thread diverged that far from your original request. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From oliver at duckasylum.com Wed Jun 26 14:16:19 2019 From: oliver at duckasylum.com (oliver at duckasylum.com) Date: Wed, 26 Jun 2019 15:16:19 +0300 Subject: gnupg-2.2.16 build fail on RHEL 7.6 due to missing gpgsm links Message-ID: <87eec3418af1cb33761e2c1e7644f305@duckasylum.com> Hello My build of gnupg-2.2.16 on RHEL Server 7.6 (Maipo) fails with the following error: > make[3]: Entering directory `/usr/local/src/gnupg-2.2.16/tests' > gcc -DHAVE_CONFIG_H -I. -I.. -I/opt/readline//include -Wall -Wno-pointer-sign -Wpointer-arith -I/opt/readline/include/readline/ -I/opt/libiconv/include/ -I/opt/libgcrypt/include/ -MT asschk.o -MD -MP -MF .deps/asschk.Tpo -c -o asschk.o asschk.c > mv -f .deps/asschk.Tpo .deps/asschk.Po > gcc -Wall -Wno-pointer-sign -Wpointer-arith -I/opt/readline/include/readline/ -I/opt/libiconv/include/ -I/opt/libgcrypt/include/ -L/opt/readline/lib/ -L/opt/libiconv/lib/ -L/opt/libgcrypt/lib/ -L/opt/readline//lib -o asschk asschk.o > srcdir=. GNUPGHOME=`/bin/pwd` GPG_AGENT_INFO= LC_ALL=C GPGSM=../sm/gpgsm ./runtest ./inittests > ../sm/gpgsm: error while loading shared libraries: libgcrypt.so.20: cannot open shared object file: No such file or directory > ../sm/gpgsm: error while loading shared libraries: libgcrypt.so.20: cannot open shared object file: No such file or directory > ../sm/gpgsm: error while loading shared libraries: libgcrypt.so.20: cannot open shared object file: No such file or directory > echo timestamp >./inittests.stamp > make[3]: Leaving directory `/usr/local/src/gnupg-2.2.16/tests' > make[2]: Leaving directory `/usr/local/src/gnupg-2.2.16/tests' > make[2]: Entering directory `/usr/local/src/gnupg-2.2.16' > make[2]: Leaving directory `/usr/local/src/gnupg-2.2.16' > make[1]: Leaving directory `/usr/local/src/gnupg-2.2.16' Indeed the ldd output is troublesome: > [user at hostname dirname]$ ldd sm/gpgsm > sm/gpgsm: /lib64/libgpg-error.so.0: no version information available (required by sm/gpgsm) > linux-vdso.so.1 => (0x00007ffe8e99e000) > libgcrypt.so.20 => not found > libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f7934861000) > libksba.so.8 => not found > libassuan.so.0 => /lib64/libassuan.so.0 (0x00007f7934650000) > libiconv.so.2 => /opt/libiconv/lib/libiconv.so.2 (0x00007f793436b000) > libc.so.6 => /lib64/libc.so.6 (0x00007f7933f9e000) > /lib64/ld-linux-x86-64.so.2 (0x00007f7934a66000) How can I satisfy the library dependencies other than putting the missing library paths into /etc/ld.so.conf and running ldconfig (I want to pass the dependencies during configure or make. Putting the paths to /etc/ld.so.conf actually made the build success)? Also the configure script is not picking up readline: > checking whether readline via "-lreadline" is present and sane... no > checking whether readline via "-lreadline -ltermcap" is present and sane... no > checking whether readline via "-lreadline -lcurses" is present and sane... no > checking whether readline via "-lreadline -lncurses" is present and sane... no > ... > Readline support: no Why isn't the --with-readline parameter honored? My configure parameters are the following: > ./configure --prefix=/opt/gnupg-2.2.16 \ > CFLAGS="-I/opt/readline/include/readline/ -I/opt/libiconv/include/ -I/opt/libgcrypt/include/" \ > LDFLAGS="-L/opt/readline/lib/ -L/opt/libiconv/lib/ -L/opt/libgcrypt/lib/" \ > --with-libgcrypt-prefix=/opt/libgcrypt/ \ > --with-libassuan-prefix=/opt/libassuan/ \ > --with-ksba-prefix=/opt/libksba/ \ > --with-npth-prefix=/opt/npth/ \ > --with-libgpg-error-prefix=/opt/libgpg-error/ \ > --with-ntbtls-prefix=/opt/ntbtls \ > --with-libiconv-prefix=/opt/libiconv/ \ > --with-readline=/opt/readline/ \ > --with-libintl-prefix=/opt/gettext/ \ > --disable-gnutls > > Thank You all in advance, > > Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From vijaikumar.kanagarajan at gmail.com Wed Jun 26 10:57:28 2019 From: vijaikumar.kanagarajan at gmail.com (Vijai Kumar K) Date: Wed, 26 Jun 2019 14:27:28 +0530 Subject: Change socketdir from ~/.gnupg to /run/user/ In-Reply-To: <875zotwuak.fsf@fifthhorseman.net> References: <20190617135821.GA1297@osboxes> <875zotwuak.fsf@fifthhorseman.net> Message-ID: <20190626085728.GB13772@osboxes> On Tue, Jun 25, 2019 at 11:37:07AM -0400, Daniel Kahn Gillmor wrote: > On Tue 2019-06-18 04:03:45 -0400, vijai kumar via Gnupg-users wrote: > > I am using gpg inside a docker container. By default, there is no > > /run/user/ in the container so gpg defaults to ~/.gnupg as socket > > directory. Is there a provision to change the socket directory later? > > Now, I would like to create /run/user/$(id -u)/gnupg and use this as > > the default socket directory. Is there a way to kill the existing agent > > and relaunch it with the new socket directory? > > Ideally, you'd ensure that /run/user/$(id -u) is created during the > session launch within the docker container, so that it's present from > the beginning. > > If you already have an agent running from before /run/user/$(id -u) > exists, you can kill it with a SIGTERM. A new agent will be launched > appropriately using /run/user/$(id -u) automatically when it is needed. > > all the best, > > --dkg Thank You Daniel! From look at my.amazin.horse Thu Jun 27 03:18:55 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Thu, 27 Jun 2019 03:18:55 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <87ftnwnaao.fsf@wheatstone.g10code.de> References: <87ftnwnaao.fsf@wheatstone.g10code.de> <462b9f638e0549e5fbe1866e35737110212a4be0.camel@googlemail.com> <39af1623f803234588d1dbe5a49bdc511f9df3f1.camel@googlemail.com> <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <3NTU2ZDNFR80P.3CN4RPAJE8LVZ@my.amazin.horse> <31CSGY53YF09J.1Z2I4F1N1HOUR@my.amazin.horse> Message-ID: <2ES6LO5BYE8C2.26HZ8BEMLHQSD@my.amazin.horse> > Please cite the section from the GDPR I assume you have looked into this already and are not asking this out of uninformedness. But, I'll bite. Article 2, "Material Scope": > (1) This Regulation applies to the processing of personal data wholly or > partly by automated means (...). There are four exceptions to general applicability, none of which even possibly apply to this scenario. We are obviously operating in the EU, so territorial scope (Article 3) also applies. Let's look at the definitions of "processing" and "personal data", then: The definition of personal data, Article 4: > (1) ?personal data? means any information relating to an identified or > identifiable natural person (?data subject?); an identifiable natural person > is one who can be identified, directly or indirectly, in particular by > reference to an identifier such as a name, (...), or an online identifier > (...); Given that there is legal commentary that even IP addresses in logs already count as personal data, I don't find it contestable that e-mail addresses do constitute personal data. Here's what "processing" means, same article: > (2) ?processing? means any operation or set of operations which is performed > on personal data or on sets of personal data, whether or not by automated > means, such as collection, recording, organisation, structuring, storage, > adaptation or alteration, retrieval, consultation, use, disclosure by > transmission, dissemination or otherwise making available, alignment or > combination, restriction, erasure or destruction; This is most certainly what we are doing. So assuming that e-mail addresses are personal data, and we process this data, there is an (exhaustive!) list of possible situations in which we are lawfully allowed to do so, two of which can potentially apply. Article 6: > 1. Processing shall be lawful only if and to the extent that at least one of > the following applies: > > (a) the data subject has given consent to the processing of his or her > personal data for one or more specific purposes; > > (...) > > (e) processing is necessary for the performance of a task carried out in the > public interest (...); The first is clear - if we have consent, we're good. The second *could* possibly be argued, but I have a hard time believing the haphazard handling of e-mail addresses on traditional keyservers serves the public interest. Even if we did assume this, there is the "right to object", which allows data subjects to object to the use of their data. Article 21: > 1. The data subject shall have the right to object, (...) to processing of > personal data concerning him or her which is based on point (e) or (f) of > Article 6(1), (...). The controller shall no longer process the personal data > unless the controller demonstrates compelling legitimate grounds for the > processing which override the interests, rights and freedoms of the data > subject (...). All in all, I find it pretty clear that GDPR does apply to processing of e-mail addresses on public keyservers. There are various nuanced conclusions one may draw, for example "it applies, but you probably won't get sued, so just keep on running them pool servers". It is unclear to me how one could look at this and conclude that keyservers aren't affected by GDPR. > and the, say, German implementation GDPR is a [regulation], not a [directive]. As such, it is an immediately enforcable law that does not require a per-country implementation to be effective. > along with relevant commentary to show why this is a legal requirement. I'm aware of work on this by folks with legal background, but due to funny academic publishing culture I'm not at liberty to share. Hopefully something will be available to the public soon. - V [regulation]: https://en.wikipedia.org/wiki/Regulation_(European_Union) [directive]: https://en.wikipedia.org/wiki/Directive_(European_Union) From dirk.gottschalk1980 at googlemail.com Fri Jun 28 09:31:07 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Fri, 28 Jun 2019 09:31:07 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <2ES6LO5BYE8C2.26HZ8BEMLHQSD@my.amazin.horse> References: <87ftnwnaao.fsf@wheatstone.g10code.de> <462b9f638e0549e5fbe1866e35737110212a4be0.camel@googlemail.com> <39af1623f803234588d1dbe5a49bdc511f9df3f1.camel@googlemail.com> <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <3NTU2ZDNFR80P.3CN4RPAJE8LVZ@my.amazin.horse> <31CSGY53YF09J.1Z2I4F1N1HOUR@my.amazin.horse> <2ES6LO5BYE8C2.26HZ8BEMLHQSD@my.amazin.horse> Message-ID: <2c6109f2ac6a3d4ea5f99055f7e46376790ad565.camel@googlemail.com> Hello Vicent. I read your explainations and will shorten them up to the points I want to reply to. Am Donnerstag, den 27.06.2019, 03:18 +0200 schrieb Vincent Breitmoser via Gnupg-users: > > (2) ?processing? means any operation or set of operations which is > > performed > > on personal data or on sets of personal data, whether or not by > > automated > > means, such as collection, recording, organisation, structuring, > > storage, > > adaptation or alteration, retrieval, consultation, use, disclosure > > by > > transmission, dissemination or otherwise making available, > > alignment or > > combination, restriction, erasure or destruction; > This is most certainly what we are doing. > So assuming that e-mail addresses are personal data, and we process > this data, there is an (exhaustive!) list of possible situations in > which we are lawfully allowed to do so, two of which can potentially > apply. Article 6: > > 1. Processing shall be lawful only if and to the extent that at > > least one of the following applies: > > (a) the data subject has given consent to the processing of his or > > her > > personal data for one or more specific purposes; > > (...) > > (e) processing is necessary for the performance of a task carried > > out in the public interest (...); > The first is clear - if we have consent, we're good. The second > *could* possibly be argued, but I have a hard time believing the > haphazard handling of e-mail addresses on traditional keyservers > serves the public interest. Even if we did assume this, there is the As one of the lawyers I work for told me, the consent could be implicated by the users upload, therefor there must be the mechanism that users can only upload their own keys, so consent is guaranteed. > "right to object", which allows data subjects to object to the use of > their data. Article 21: > > 1. The data subject shall have the right to object, (...) to > > processing of personal data concerning him or her which is based on > > point (e) or (f) of Article 6(1), (...). The controller shall no > > longer process the personal data unless the controller demonstrates > > compelling legitimate grounds for the processing which override the > > interests, rights and freedoms of the data subject (...). > All in all, I find it pretty clear that GDPR does apply to processing > of e-mail addresses on public keyservers. There are various nuanced > conclusions one may draw, for example "it applies, but you probably > won't get sued, so just keep on running them pool servers". It is > unclear to me how one could look at this and conclude that keyservers > aren't affected by GDPR. The User knows how and why the data is processed, if he uploads his key to the server. A deletion has to be possible by the regulation, SKS lacks this mechanism. I haven't tested the new server yet, but I'm planning to do this in the next day. As far as I read, deletion is possible there. > > and the, say, German implementation > GDPR is a [regulation], not a [directive]. As such, it is an > immediately enforcable law that does not require a per-country > implementation to be effective. Yes and no. The EU construct is a little bit strange in this manner, but GDPR was transferred into german law by the renewal of the BDSG last year. > > along with relevant commentary to show why this is a legal > > requirement. > I'm aware of work on this by folks with legal background, but due to > funny academic publishing culture I'm not at liberty to > share. Hopefully something will be available to the public soon. Oh yes, academic publishing culture is indeed a little strange. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From dirk.gottschalk1980 at googlemail.com Fri Jun 28 09:33:22 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Fri, 28 Jun 2019 09:33:22 +0200 Subject: gpg-agent systemd user service [was: Re: GnuPG and SSH_AUTH_SOCK value] In-Reply-To: <20190626054711.GA3721@c720-r342378> References: <20190621112017.GA2077@c720-r349041> <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041> <874l4ioydb.fsf@wheatstone.g10code.de> <20190623102134.GA1923@c720-r349041> <87ef3hwvf8.fsf@fifthhorseman.net> <20190626054711.GA3721@c720-r342378> Message-ID: <0d91aba972e4c1abafe89b8230072a9e158daefb.camel@googlemail.com> Am Mittwoch, den 26.06.2019, 07:47 +0200 schrieb Matthias Apitz: > El d?a martes, junio 25, 2019 a las 11:12:43a. m. -0400, Daniel Kahn > Gillmor escribi?: > > On Tue 2019-06-25 13:07:03 +0200, Dirk Gottschalk via Gnupg-users > > wrote: > > > This is my $HOME/.config/systemd/user/gpg-agent.service: > > If you're using gpg-agent as a systemd user service, please use the > > systemd unit files (.service and .socket definitions) that ship > > with > > GnuPG itself. > > > > ... > Thanks for all the helping hands and hints about systemd(8), but > FreeBSD > normally does not run/use this. AFAIK, there is not even an official > port of it in the FreeBSD's ports collection. I'm sorry, I overread that you are asking about FreeBSD. I had just Linux in mind. Did't want to steal your time. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mkesper at schokokeks.org Fri Jun 28 10:04:44 2019 From: mkesper at schokokeks.org (Michael Kesper) Date: Fri, 28 Jun 2019 10:04:44 +0200 Subject: GnuPG and SSH_AUTH_SOCK value In-Reply-To: <20190623102134.GA1923@c720-r349041> References: <20190621112017.GA2077@c720-r349041> <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041> <874l4ioydb.fsf@wheatstone.g10code.de> <20190623102134.GA1923@c720-r349041> Message-ID: Hi Matthias, On 23.06.19 12:21, Matthias Apitz wrote: > I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE: This makes your setup depend on a suid binary. There have been some security issues about that, so maybe it's wise to revise that decision? For example: https://www.exploit-db.com/exploits/45908 Bye Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Jun 28 10:23:29 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 28 Jun 2019 04:23:29 -0400 Subject: GnuPG and SSH_AUTH_SOCK value In-Reply-To: References: <20190621112017.GA2077@c720-r349041> <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041> <874l4ioydb.fsf@wheatstone.g10code.de> <20190623102134.GA1923@c720-r349041> Message-ID: <87ftnup18e.fsf@fifthhorseman.net> On Fri 2019-06-28 10:04:44 +0200, Michael Kesper wrote: > On 23.06.19 12:21, Matthias Apitz wrote: >> I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE: > > This makes your setup depend on a suid binary. Can you give more details? I know that some older systems did rely on X or startx or something being setuid, but i think more modern systems don't require that. On a debian testing (buster) system, for example, i don't believe that any of the binaries are suid. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mkesper at schokokeks.org Fri Jun 28 11:09:36 2019 From: mkesper at schokokeks.org (Michael Kesper) Date: Fri, 28 Jun 2019 11:09:36 +0200 Subject: GnuPG and SSH_AUTH_SOCK value In-Reply-To: <87ftnup18e.fsf@fifthhorseman.net> References: <20190621112017.GA2077@c720-r349041> <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041> <874l4ioydb.fsf@wheatstone.g10code.de> <20190623102134.GA1923@c720-r349041> <87ftnup18e.fsf@fifthhorseman.net> Message-ID: Hi Daniel, On 28.06.19 10:23, Daniel Kahn Gillmor wrote: > On Fri 2019-06-28 10:04:44 +0200, Michael Kesper wrote: >> On 23.06.19 12:21, Matthias Apitz wrote: >>> I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE: >> >> This makes your setup depend on a suid binary. > > Can you give more details? I know that some older systems did rely on X > or startx or something being setuid, but i think more modern systems > don't require that. On a debian testing (buster) system, for example, i > don't believe that any of the binaries are suid. The setuid binary is called xserver-xorg-legacy and can be installed in buster (new installs don't get it afaik, but I'm not sure about upgrading): https://packages.debian.org/de/buster/xserver-xorg-legacy Matthias explicitly mentioned he used startx so I think this is relevant. Bye Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From mkesper at schokokeks.org Fri Jun 28 11:12:36 2019 From: mkesper at schokokeks.org (Michael Kesper) Date: Fri, 28 Jun 2019 11:12:36 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <2ES6LO5BYE8C2.26HZ8BEMLHQSD@my.amazin.horse> References: <87ftnwnaao.fsf@wheatstone.g10code.de> <462b9f638e0549e5fbe1866e35737110212a4be0.camel@googlemail.com> <39af1623f803234588d1dbe5a49bdc511f9df3f1.camel@googlemail.com> <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <3NTU2ZDNFR80P.3CN4RPAJE8LVZ@my.amazin.horse> <31CSGY53YF09J.1Z2I4F1N1HOUR@my.amazin.horse> <2ES6LO5BYE8C2.26HZ8BEMLHQSD@my.amazin.horse> Message-ID: <06c1b0ee-ab5c-6fcc-aeb7-14cf0919953d@schokokeks.org> Hi all, On 27.06.19 03:18, Vincent Breitmoser via Gnupg-users wrote: > The definition of personal data, Article 4: > >> (1) ?personal data? means any information relating to an identified or >> identifiable natural person (?data subject?); an identifiable natural person >> is one who can be identified, directly or indirectly, in particular by >> reference to an identifier such as a name, (...), or an online identifier >> (...); > > Given that there is legal commentary that even IP addresses in logs already > count as personal data, I don't find it contestable that e-mail addresses do > constitute personal data. Definitely. If you can identify someone by data, it IS personal data. As many email addresses are firstname.lastname@ they are already directly identifiable. See also: https://www.gdpreu.org/the-regulation/key-concepts/personal-data/ Best Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Jun 28 14:53:41 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 28 Jun 2019 08:53:41 -0400 Subject: GnuPG and SSH_AUTH_SOCK value In-Reply-To: References: <20190621112017.GA2077@c720-r349041> <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041> <874l4ioydb.fsf@wheatstone.g10code.de> <20190623102134.GA1923@c720-r349041> <87ftnup18e.fsf@fifthhorseman.net> Message-ID: <87a7e1q3ai.fsf@fifthhorseman.net> On Fri 2019-06-28 11:09:36 +0200, Michael Kesper wrote: > On 28.06.19 10:23, Daniel Kahn Gillmor wrote: >> On Fri 2019-06-28 10:04:44 +0200, Michael Kesper wrote: >>> On 23.06.19 12:21, Matthias Apitz wrote: >>>> I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE: >>> >>> This makes your setup depend on a suid binary. >> >> Can you give more details? I know that some older systems did rely on X >> or startx or something being setuid, but i think more modern systems >> don't require that. On a debian testing (buster) system, for example, i >> don't believe that any of the binaries are suid. > > The setuid binary is called xserver-xorg-legacy and can be installed in > buster (new installs don't get it afaik, but I'm not sure about upgrading): > https://packages.debian.org/de/buster/xserver-xorg-legacy > Matthias explicitly mentioned he used startx so I think this is > relevant. I also use startx on buster systems, but i don't have xserver-xorg-legacy installed, so i think this is not the strict dependency it sounded like originally. I know that i used to depend on a setuid X server, so i'm gratefuly to the folks who did the work to remove that setuid requirement! Anyway, i think we're pretty far off-topic here, so i'll drop off this thread, just wanted to confirm that i hadn't missed something. all the best, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From steffen at sdaoden.eu Fri Jun 28 19:07:18 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 28 Jun 2019 19:07:18 +0200 Subject: GnuPG and SSH_AUTH_SOCK value In-Reply-To: <87ftnup18e.fsf@fifthhorseman.net> References: <20190621112017.GA2077@c720-r349041> <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041> <874l4ioydb.fsf@wheatstone.g10code.de> <20190623102134.GA1923@c720-r349041> <87ftnup18e.fsf@fifthhorseman.net> Message-ID: <20190628170718.9NHKU%steffen@sdaoden.eu> Daniel Kahn Gillmor via Gnupg-users wrote in <87ftnup18e.fsf at fifthhorsem\ an.net>: |On Fri 2019-06-28 10:04:44 +0200, Michael Kesper wrote: |> On 23.06.19 12:21, Matthias Apitz wrote: |>> I'm used to use 'startx' and ~/.xinitrc to bring up Xorg+KDE: |> |> This makes your setup depend on a suid binary. | |Can you give more details? I know that some older systems did rely on X |or startx or something being setuid, but i think more modern systems |don't require that. On a debian testing (buster) system, for example, i |don't believe that any of the binaries are suid. ..because some packagers do CRUX to avoid it, maybe because they do not want to violate some policy. For example, for the MUA i maintain, Debian ships with the privilege-separated "dotlock" helper, but does not install it SETUID. This is good enough for the shared mail directory the way Debian does it, in fact the package maintainer is pretty clever, right, but of course this is not how it is designed; today: it was a SETGID helper in the past, but that does not work on eg. OpenBSD where only root can write in the mail spool. And since this MUA supports multiple mail spools, it will not work unless they are setup in exactly the same way. But only normal file-locking, as is the chosen approach on OpenBSD (for my MUA), is not the way the Debian maintainer wants to go. Well, this is his choice. (Besides i am in total favour of not having SETUID, not only because i had a CVE myself. Here Xorg still is SETUID, but i have never looked too deep. For graphics hardware access, you need to have access to hardware, no. Ie., whether hardware is designed so that this becomes possible, i do not know. Being able to start a program SETUID, open some files, and then enter a restricted mode which has lost root rights, i do not feel bad about. Like the FreeBSD capsicum thing, or even CloudABI. Maybe i even prefer being able to search SETUID and have a list, instead of having very complicated configuration settings, and CRUX, hidden here and there. But i am not a security researcher, i just try to do a little thing right.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From ryan at digicana.com Sat Jun 29 19:51:35 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Sat, 29 Jun 2019 17:51:35 +0000 Subject: SKS Keyserver Network Under Attack Message-ID: https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f -Ryan McGinnis http://bigstormpicture.com PGP: 486ED7AD Sent with ProtonMail Secure Email -------------- next part -------------- An HTML attachment was scrubbed... URL: From sac at 300baud.de Sat Jun 29 21:10:14 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 29 Jun 2019 21:10:14 +0200 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: Message-ID: Ryan McGinnis via Gnupg-users wrote: > https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f > > -Ryan McGinnis > http://bigstormpicture.com > PGP: 486ED7AD > Sent with ProtonMail Secure Email No problen, we now have super modern GDPR compliant hagrid, WKD, keybase and good old pgp.com key server. :-) New version of Enigmail will default to hagrid. :-) Regards Stefan From andrewg at andrewg.com Sun Jun 30 01:33:22 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 30 Jun 2019 00:33:22 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <87ef3my885.fsf@fifthhorseman.net> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> Message-ID: <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> > On 21 Jun 2019, at 21:49, Daniel Kahn Gillmor wrote: > > So if we decide we only want to address use case (c), then it doesn't > seem too crazy to imagine reconciliation among multiple installations of > all the distributed, cryptographically-validated *non-identity* data > that hagrid is designed to distribute. And this should be > fully-compatible with hagrid's implementation; each instance which can > simply augment the reconciled data with the identity information that it > has independently verified. Indeed, c) was exactly the killer use case I had in mind. On the other hand, b) is also quite useful in the short to medium term, until all mail providers decide to support WKD etc. And considering that some companies still don?t fully support PGP/MIME after nearly twenty years of being the preferred standard (I?m looking at you, Apple), ?short to medium? effectively means ?indefinitely?. So maybe we shouldn?t think of keyservers as storage repositories, but rather as search engines. The keyservers should not be authoritative, but they should be a best effort directory of where the authoritative locations are, combined with a cache of the non-identity cryptographic material in case the authoritative locations get DOSed. If the authoritative location is not on a keyserver, then we do not need to sync arbitrary data between keyservers, just a list of location hints. The keyservers would then fetch from the authoritative locations and decide for themselves how much of the content to cache. A From ryan at digicana.com Sun Jun 30 03:21:14 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Sun, 30 Jun 2019 01:21:14 +0000 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: Message-ID: Interesting discussion thread on this over at HN: https://news.ycombinator.com/item?id=20312826 -Ryan McGinnis http://bigstormpicture.com PGP: 486ED7AD Sent with ProtonMail Secure Email On Sat, Jun 29, 2019 at 12:51, Ryan McGinnis wrote: > https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f > > -Ryan McGinnis > http://bigstormpicture.com > PGP: 486ED7AD > Sent with ProtonMail Secure Email -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sun Jun 30 08:26:55 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 30 Jun 2019 02:26:55 -0400 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: Message-ID: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> > https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f I stand by what I wrote. As usual, don't read the comments unless you want to despair for humanity. From mirimir at riseup.net Sun Jun 30 09:36:19 2019 From: mirimir at riseup.net (Mirimir) Date: Sun, 30 Jun 2019 00:36:19 -0700 Subject: SKS Keyserver Network Under Attack In-Reply-To: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> Message-ID: On 06/29/2019 11:26 PM, Robert J. Hansen wrote: >> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f > > I stand by what I wrote. > > As usual, don't read the comments unless you want to despair for humanity. It sounds like SKS is dead meat. And hagrid is coming. And you advise: | High-risk users should stop using the keyserver network immediately. So OK, I can purge requests to SKS keyservers from my machines. But what about upstream impacts? As I understand it, GnuPG authentication is pervasive. And I suspect that getting missing keys from SKS is common. As an error trap, if nothing else. How bad could this get? From rjh at sixdemonbag.org Sun Jun 30 10:19:19 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 30 Jun 2019 04:19:19 -0400 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> Message-ID: <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> > How bad could this get? (I am sputteringly angry over this entire thing: please understand this and give a charitable read to what I write. I appreciate it.) Hard to say. One of the big problems we have is the size of the existing codebase. Once people have GnuPG installed people overwhelmingly like to leave it alone. We still get people coming onto this list asking for support with GnuPG *1.2*. So for these installations, these "we're going to install it and forget it"s? They're screwed. Sooner or later they'll import a poisoned certificate, GnuPG will get wedged, and it will appear as if GnuPG just stopped working. It might happen tomorrow or it might happen in five years. We don't know, but it will happen. There are other groups that run human networks in dangerous places. (There are many of them: Medicins Sans Frontiers, Reuters, and more.) The people who are running around Syria treating casualties or doing political news reporting from Gaza are overwhelmingly not computer nerds. They know they're supposed to run "gpg --refresh-keys" from time to time to get the latest revocations. They do it this time, and GnuPG breaks horribly. Odds are good they'll say "sod this, I can't trust this crap" and throw it away. There are a ton of tiny little poorly-maintained systems in out-of-the-way places that get completely overlooked until things break. Those, too, have good odds of getting wedged the first time they encounter a poisoned certificate. The next version of Enigmail will no longer use the SKS network by default. Great! But what about existing Enigmail users? They'll see a signature, click "Import Key", and ... bam. They're likely not going to think that someone's performing a malicious attack by poisoning certificates: they're going to think "this is crap" and walk away. Right now only three certificates are known to be affected: mine, dkg's, and Kristian's. I expect that number to rise, either due to the original jerk figuring this is fun, or due to copycats getting in on the action. From andrewg at andrewg.com Sun Jun 30 10:34:52 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 30 Jun 2019 09:34:52 +0100 Subject: SKS Keyserver Network Under Attack In-Reply-To: <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: > On 30 Jun 2019, at 09:19, Robert J. Hansen wrote: > > The next version of Enigmail will no longer use the SKS network by > default. Great! But what about existing Enigmail users? They'll see a > signature, click "Import Key", and ... bam. They're likely not going to > think that someone's performing a malicious attack by poisoning > certificates: they're going to think "this is crap" and walk away. Thankfully there is a practical - if drastic - solution for all OpenPGP users everywhere. Point pool.sks-keyservers.net (and its various aliases) somewhere else. The question is where to and how soon. A From rjh at sixdemonbag.org Sun Jun 30 10:37:14 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 30 Jun 2019 04:37:14 -0400 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: <8c1cff43-ec63-2a9c-e5f6-f042b54db30b@sixdemonbag.org> > Thankfully there is a practical - if drastic - solution for all > OpenPGP users everywhere. Point pool.sks-keyservers.net (and its > various aliases) somewhere else. The question is where to and how > soon. (I am certain Andrew has already considered this: I am making explicit what I think Andrew considered to be implicit.) The obvious choice there is hkps://keys.openpgp.org. The problem there is keys.openpgp.org is not a drop-in replacement for SKS, and there's a tremendous chance of breaking workflows in unpredictable places. From andrewg at andrewg.com Sun Jun 30 10:50:18 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 30 Jun 2019 09:50:18 +0100 Subject: SKS Keyserver Network Under Attack In-Reply-To: <8c1cff43-ec63-2a9c-e5f6-f042b54db30b@sixdemonbag.org> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <8c1cff43-ec63-2a9c-e5f6-f042b54db30b@sixdemonbag.org> Message-ID: <5FD00501-9269-4FAD-A76E-146BA7BA8E31@andrewg.com> >> Thankfully there is a practical - if drastic - solution for all >> OpenPGP users everywhere. Point pool.sks-keyservers.net (and its >> various aliases) somewhere else. The question is where to and how >> soon. > > (I am certain Andrew has already considered this: I am making explicit > what I think Andrew considered to be implicit.) > > The obvious choice there is hkps://keys.openpgp.org. The problem there > is keys.openpgp.org is not a drop-in replacement for SKS, and there's a > tremendous chance of breaking workflows in unpredictable places. > Yes, this is the ?how soon?. We are *nowhere near* prepared enough to take that step now. But a solution exists (at least in principle) that does not require end users to take any action. The big obstacles are: 1. scalability. A non-distributed key service could potentially collapse if global hkp(s) traffic was redirected to it. 2. reliability. There would need to be enough failover capacity in the new system to withstand individual server failure. 3. interoperability. The replacement service would need to be fully compatible with all existing clients. DKG?s internet draft shows how hard this will be to ensure in practice without simply replicating the problems of the existing network. We?ve known this day was coming for some time. We?ve just got a fire lit under our collective backsides. A From mirimir at riseup.net Sun Jun 30 11:21:30 2019 From: mirimir at riseup.net (Mirimir) Date: Sun, 30 Jun 2019 02:21:30 -0700 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: On 06/30/2019 01:34 AM, Andrew Gallagher wrote: > >> On 30 Jun 2019, at 09:19, Robert J. Hansen wrote: >> >> The next version of Enigmail will no longer use the SKS network by >> default. Great! But what about existing Enigmail users? They'll see a >> signature, click "Import Key", and ... bam. They're likely not going to >> think that someone's performing a malicious attack by poisoning >> certificates: they're going to think "this is crap" and walk away. > > Thankfully there is a practical - if drastic - solution for all OpenPGP users everywhere. Point pool.sks-keyservers.net (and its various aliases) somewhere else. The question is where to and how soon. > > A This is undoubtedly a naive question. But anyway, would it be feasible to test keys by importing them, and seeing which ones break OpenPGP? Maybe do it in minimal Docker containers? And then somehow block access to those keys? Or is blocking just as impossible as deleting? I know that wouldn't help people whose keys had been poisoned. But at least it would help protect complex systems that rely on OpenPGP. And if resource requirements would be impossible, what about focusing on the most important keys? For key packages, say. From sac at 300baud.de Sun Jun 30 11:24:08 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 30 Jun 2019 11:24:08 +0200 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: Andrew Gallagher wrote: > > > On 30 Jun 2019, at 09:19, Robert J. Hansen wrote: > > > > The next version of Enigmail will no longer use the SKS network by > > default. Great! But what about existing Enigmail users? They'll see a > > signature, click "Import Key", and ... bam. They're likely not going to > > think that someone's performing a malicious attack by poisoning > > certificates: they're going to think "this is crap" and walk away. > > Thankfully there is a practical - if drastic - solution for all OpenPGP users > everywhere. Point pool.sks-keyservers.net (and its various aliases) somewhere > else. The question is where to and how soon. Can someone please explain to me why the GnuPG flag for key servers --no-modify is in GnuPG and why the authors of key server software did not implemented this feature? Regards Stefan From rjh at sixdemonbag.org Sun Jun 30 11:37:02 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 30 Jun 2019 05:37:02 -0400 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: <3c238171-9818-c336-81fd-fa0776efedbe@sixdemonbag.org> > Can someone please explain to me why the GnuPG flag for key servers > --no-modify is in GnuPG and why the authors of key server software > did not implemented this feature? It's pretty unreasonable to think a piece of software from 2003, meant as a drop-in replacement for software written in 1993, would implement a feature that first appeared in GnuPG around 2013.[1] If your next question is, "well, why doesn't SKS get modernized?", the answer is "with what personnel and what budget?" SKS doesn't even have a maintainer, for God's sake. [1] That "around 2013" is a guess: I don't know off the top of my head when that was first added to GnuPG. From sac at 300baud.de Sun Jun 30 11:50:34 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 30 Jun 2019 11:50:34 +0200 Subject: SKS Keyserver Network Under Attack In-Reply-To: <3c238171-9818-c336-81fd-fa0776efedbe@sixdemonbag.org> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <3c238171-9818-c336-81fd-fa0776efedbe@sixdemonbag.org> Message-ID: Robert J. Hansen wrote: > > Can someone please explain to me why the GnuPG flag for key servers > > --no-modify is in GnuPG and why the authors of key server software > > did not implemented this feature? > > It's pretty unreasonable to think a piece of software from 2003, meant > as a drop-in replacement for software written in 1993, would implement a > feature that first appeared in GnuPG around 2013.[1] > [1] That "around 2013" is a guess: I don't know off the top of my head > when that was first added to GnuPG. Thanks for the info. Regards Stefan From look at my.amazin.horse Sun Jun 30 12:01:43 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Sun, 30 Jun 2019 12:01:43 +0200 Subject: SKS Keyserver Network Under Attack In-Reply-To: <5FD00501-9269-4FAD-A76E-146BA7BA8E31@andrewg.com> References: <5FD00501-9269-4FAD-A76E-146BA7BA8E31@andrewg.com> <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <8c1cff43-ec63-2a9c-e5f6-f042b54db30b@sixdemonbag.org> Message-ID: <3NIMRZA7S9QFH.2EVVQ60BIIDJN@my.amazin.horse> > 3. interoperability. The replacement service would need to be fully compatible > with all existing clients. Depending on what you mean by "fully compatible". The single biggest issue is importing keys that don't have identity info on them. I submitted a patch to GnuPG to fix this issue, but for some reason that is beyond me there seems to be resistance to merging it: https://dev.gnupg.org/T4393 - V From andrewg at andrewg.com Sun Jun 30 12:03:06 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 30 Jun 2019 11:03:06 +0100 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: > On 30 Jun 2019, at 10:21, Mirimir via Gnupg-users wrote: > > This is undoubtedly a naive question. But anyway, would it be feasible > to test keys by importing them, and seeing which ones break OpenPGP? > Maybe do it in minimal Docker containers? And then somehow block access > to those keys? Because a) it?s enumerating badness [1] but more importantly b) it?s punishing the victim. Protecting the ecosystem by banning RJH and DKG?s keys from the keyservers entirely is doing the bad guys? work for them. A [1] https://www.ranum.com/security/computer_security/editorials/dumb/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Sun Jun 30 12:04:23 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 30 Jun 2019 11:04:23 +0100 Subject: SKS Keyserver Network Under Attack In-Reply-To: <3NIMRZA7S9QFH.2EVVQ60BIIDJN@my.amazin.horse> References: <5FD00501-9269-4FAD-A76E-146BA7BA8E31@andrewg.com> <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <8c1cff43-ec63-2a9c-e5f6-f042b54db30b@sixdemonbag.org> <3NIMRZA7S9QFH.2EVVQ60BIIDJN@my.amazin.horse> Message-ID: <8DC62AB4-F950-4C22-A57E-D9CE166021FE@andrewg.com> > On 30 Jun 2019, at 11:01, Vincent Breitmoser wrote: > > The single biggest issue is > importing keys that don't have identity info on them. I submitted a patch to > GnuPG to fix this issue, but for some reason that is beyond me there seems to be > resistance to merging it: Unfortunately even if that patch were merged it doesn?t solve the issue, which is compatibility with the existing client base. A From rjh at sixdemonbag.org Sun Jun 30 12:10:07 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 30 Jun 2019 06:10:07 -0400 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: > Because a) it?s enumerating badness [1] but more importantly b) it?s > punishing the victim. Protecting the ecosystem by banning RJH and DKG?s > keys from the keyservers entirely is doing the bad guys? work for them. There's an important c): c) what happens when they go after more certificates? If you're willing to blackhole two certs, great. Where does it stop? How many certs can the strong set stand to lose? From mirimir at riseup.net Sun Jun 30 12:49:55 2019 From: mirimir at riseup.net (Mirimir) Date: Sun, 30 Jun 2019 03:49:55 -0700 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: On 06/30/2019 03:10 AM, Robert J. Hansen wrote: >> Because a) it?s enumerating badness [1] but more importantly b) it?s >> punishing the victim. Protecting the ecosystem by banning RJH and DKG?s >> keys from the keyservers entirely is doing the bad guys? work for them. Currently, we know that three keys are bad. How soon do you think that bad keys will outnumber good ones? Weeks? Months? Years? > There's an important c): > > c) what happens when they go after more certificates? > > If you're willing to blackhole two certs, great. Where does it stop? > How many certs can the strong set stand to lose? Your third point is actually why I suggested this. Maybe I'm just twisted, but what if some dickhead goes after certs that would break stuff for millions of people? One might, for example, block Linux kernel maintenance and development. Maybe just before using some 0-day. It would stop when certs can no longer be poisoned. And I don't see the downside. I mean, what good does it do to have people downloading keys that break their stuff? I don't see that as "doing the bad guys? work for them". I see it as preventing bad guys escalating from hurting a few people to doing serious damage. That's not "punishing the victim". Also, I presume that key owners could temporarily disable signature checking, delete malicious signatures, and put their keys on secure keyservers. But until secure keyservers exist at requisite scale, blackholing seems like the simplest option. If it's doable, anyway. From ullbeking at andrewnesbit.org Sun Jun 30 13:48:56 2019 From: ullbeking at andrewnesbit.org (U'll Be King of the Stars) Date: Sun, 30 Jun 2019 12:48:56 +0100 Subject: SKS Keyserver Network Under Attack In-Reply-To: <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: <3f88910b-fcfd-e8b9-62e0-077a5f35f584@andrewnesbit.org> On 30/06/2019 09:19, Robert J. Hansen wrote: > Right now only three certificates are known to be affected: mine, dkg's, > and Kristian's. I must have missed the memo describing the exact nature of the problem. Could you please provide a link to something (email message, web page) that explains what is going on? Thanks! Kind regards, Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 From ryan at digicana.com Sun Jun 30 14:33:08 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Sun, 30 Jun 2019 12:33:08 +0000 Subject: SKS Keyserver Network Under Attack In-Reply-To: <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: What would have prevented a state level actor from activating this exploit on a wide level during a time when it would have been most effective for them? I have to believe that the fine folks who can put an APT in your air-gapped computer?s video card bios have been aware of this attack for quite some time and probably have an entire laundry list of other similarly devastating attacks. -Ryan McGinnis http://bigstormpicture.com PGP: 486ED7AD Sent with ProtonMail Secure Email On Sun, Jun 30, 2019 at 03:19, Robert J. Hansen wrote: >> How bad could this get? > > (I am sputteringly angry over this entire thing: please understand this > and give a charitable read to what I write. I appreciate it.) > > Hard to say. > > One of the big problems we have is the size of the existing codebase. > Once people have GnuPG installed people overwhelmingly like to leave it > alone. We still get people coming onto this list asking for support > with GnuPG *1.2*. So for these installations, these "we're going to > install it and forget it"s? > > They're screwed. Sooner or later they'll import a poisoned certificate, > GnuPG will get wedged, and it will appear as if GnuPG just stopped > working. It might happen tomorrow or it might happen in five years. We > don't know, but it will happen. > > There are other groups that run human networks in dangerous places. > (There are many of them: Medicins Sans Frontiers, Reuters, and more.) > The people who are running around Syria treating casualties or doing > political news reporting from Gaza are overwhelmingly not computer > nerds. They know they're supposed to run "gpg --refresh-keys" from time > to time to get the latest revocations. They do it this time, and GnuPG > breaks horribly. Odds are good they'll say "sod this, I can't trust > this crap" and throw it away. > > There are a ton of tiny little poorly-maintained systems in > out-of-the-way places that get completely overlooked until things break. > Those, too, have good odds of getting wedged the first time they > encounter a poisoned certificate. > > The next version of Enigmail will no longer use the SKS network by > default. Great! But what about existing Enigmail users? They'll see a > signature, click "Import Key", and ... bam. They're likely not going to > think that someone's performing a malicious attack by poisoning > certificates: they're going to think "this is crap" and walk away. > > Right now only three certificates are known to be affected: mine, dkg's, > and Kristian's. I expect that number to rise, either due to the > original jerk figuring this is fun, or due to copycats getting in on the > action. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sun Jun 30 14:44:43 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 30 Jun 2019 08:44:43 -0400 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: <45f2bc73-b2b2-80af-9649-2f21ae19d6bf@sixdemonbag.org> > What would have prevented a state level actor from activating this > exploit on a wide level during a time when it would have been most > effective for them? A nation-state with a professional intelligence service probably isn't very interested in taking down the keyserver network. Why should they take down something that's not a big priority for them, especially if it'll cost them a lot of international goodwill if it gets attributed to them? This has all the hallmarks of a child playing with matches and clapping with glee as the house catches fire. From ryan at digicana.com Sun Jun 30 15:17:05 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Sun, 30 Jun 2019 13:17:05 +0000 Subject: SKS Keyserver Network Under Attack In-Reply-To: <45f2bc73-b2b2-80af-9649-2f21ae19d6bf@sixdemonbag.org> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <45f2bc73-b2b2-80af-9649-2f21ae19d6bf@sixdemonbag.org> Message-ID: I guess that?s one way to look at it, but if your end users are dissidents and journalists communicating in happy fun places or developers signing critical software, then surely you?d want the product to be resilient against 10 year old trivial attacks from your users? adversaries. I do understand the ?with what resources? argument; I imagine there is no way of getting around that. But if that is the end response to stuff like this then it seems more an argument that people should not be using this software system for important, serious applications. For the secure communications functionality I suspect this has been the target end users? perception for quite some time, and a whole slew of arguably better secure communications systems have risen to fill that need - but GPG is still used heavily in signing important files. -Ryan McGinnis http://bigstormpicture.com PGP: 486ED7AD Sent with ProtonMail Secure Email On Sun, Jun 30, 2019 at 07:44, Robert J. Hansen wrote: >> What would have prevented a state level actor from activating this >> exploit on a wide level during a time when it would have been most >> effective for them? > > A nation-state with a professional intelligence service probably isn't > very interested in taking down the keyserver network. Why should they > take down something that's not a big priority for them, especially if > it'll cost them a lot of international goodwill if it gets attributed to > them? > > This has all the hallmarks of a child playing with matches and clapping > with glee as the house catches fire. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sun Jun 30 15:50:09 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 30 Jun 2019 09:50:09 -0400 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <45f2bc73-b2b2-80af-9649-2f21ae19d6bf@sixdemonbag.org> Message-ID: > I guess that?s one way to look at it, but if your end users are > dissidents and journalists communicating?in happy fun places or > developers signing critical software,?then surely you?d want the > product?to be resilient against?10 year old?trivial?attacks from your > users? adversaries. I feel like I am screaming into the void here. I'm going to be quite blunt because the message is just not getting through: I don't get to decide these things. Stop implying that I do. Stop blaming me for other people's decisions. And stop thinking that I have *anything whatsoever to do with the keyservers*. I don't. I understand them but I am not a developer on them. I don't even run a keyserver. And if you knew the first thing about the keyservers you would know this without needing me to tell you. So please forgive me for not wanting to have a conversation with you. I am getting very tired of people confusing "Rob understands the current mess" with "so I'm going to impugn his competence". From andrewg at andrewg.com Sun Jun 30 16:00:21 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 30 Jun 2019 15:00:21 +0100 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: <3c41fbc2-4862-289d-d0ed-8ff3484ea98b@andrewg.com> On 2019/06/30 11:49, Mirimir via Gnupg-users wrote: > It would stop when certs can no longer be poisoned. And I don't see the > downside. I mean, what good does it do to have people downloading keys > that break their stuff? > > I don't see that as "doing the bad guys? work for them". I see it as > preventing bad guys escalating from hurting a few people to doing > serious damage. That's not "punishing the victim". It prevents escalation, yes. But at the expense of exiling the targeted people from the network - which may well be the attacker's real intent. Any "solution" that turns a general problem into a problem for a small number of *specific individuals* is not a solution, it's a lynching. I'm sure those specific individuals will be thankful that they've been thrown under the bus for the greater good. I'm sure nobody else will be looking over their shoulder wondering whether they'll be next. We solve this issue for *everyone*, or we all go home. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sun Jun 30 16:33:15 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 30 Jun 2019 10:33:15 -0400 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: > Your third point is actually why I suggested this. Maybe I'm just > twisted, but what if some dickhead goes after certs that would break > stuff for millions of people? One might, for example, block Linux kernel > maintenance and development. Maybe just before using some 0-day. For whatever it's worth, as soon as I heard word there were poisoned certificates in the strong set I spoke to a friend who's well-connected in the kernel community and made sure to pass on the warning and the mitigation. I am not worried about the kernel hackers being hit. They're technically savvy, close-knit, and largely self-sufficient technologically. I'm very worried about people who lack technical skills (for many people, just editing a config file is beyond them), who are in loose contact with the GnuPG/keyserver community (people who might check in once a year to see if there's any major updates), who are dependent on others for their communications ("I don't know how this works, my IT department sets it up for me"). Those people are -very- vulnerable to this. They're going to get hit hard. > It would stop when certs can no longer be poisoned. Please show me how we can prevent certs from being poisoned. This is a phenomenally hard problem. You are handwaving away a huge amount of difficulty. What you are saying here is, "it would never end." > I don't see that as "doing the bad guys? work for them". I see it as > preventing bad guys escalating from hurting a few people to doing > serious damage. That's not "punishing the victim". "Look, this one guy who just got mugged? Clearly the street gang doesn't like him. So if we just, you know, don't help him, then the gang won't also go after us. We're not 'punishing the victim'. We're just saying, the needs of the many outweigh the needs of the few. I mean, it's too bad, what's happening to him. And it's too bad the gang is making us turn our backs and walk away. I bet that once we're a block away we're not going to be able to hear him screaming. Come on, let's walk faster." From ryan at digicana.com Sun Jun 30 16:37:30 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Sun, 30 Jun 2019 14:37:30 +0000 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <45f2bc73-b2b2-80af-9649-2f21ae19d6bf@sixdemonbag.org> Message-ID: I can?t speak for others, but I wasn?t suggesting you were personally responsible for where things are right now, only making observations about the utility of continuing to use the product going forward, and what the targeted end users likely expect from the software. -Ryan McGinnis http://bigstormpicture.com PGP: 486ED7AD Sent with ProtonMail Secure Email On Sun, Jun 30, 2019 at 08:50, Robert J. Hansen wrote: >> I guess that?s one way to look at it, but if your end users are >> dissidents and journalists communicating in happy fun places or >> developers signing critical software, then surely you?d want the >> product to be resilient against 10 year old trivial attacks from your >> users? adversaries. > > I feel like I am screaming into the void here. I'm going to be quite > blunt because the message is just not getting through: > > I don't get to decide these things. Stop implying that I do. Stop > blaming me for other people's decisions. And stop thinking that I have > *anything whatsoever to do with the keyservers*. I don't. I understand > them but I am not a developer on them. I don't even run a keyserver. > And if you knew the first thing about the keyservers you would know this > without needing me to tell you. > > So please forgive me for not wanting to have a conversation with you. I > am getting very tired of people confusing "Rob understands the current > mess" with "so I'm going to impugn his competence". > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerry at seibercom.net Sun Jun 30 15:13:23 2019 From: jerry at seibercom.net (Jerry) Date: Sun, 30 Jun 2019 09:13:23 -0400 Subject: SKS Keyserver Network Under Attack In-Reply-To: <45f2bc73-b2b2-80af-9649-2f21ae19d6bf@sixdemonbag.org> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <45f2bc73-b2b2-80af-9649-2f21ae19d6bf@sixdemonbag.org> Message-ID: <20190630091323.00006c4e@seibercom.net> On Sun, 30 Jun 2019 08:44:43 -0400, Robert J. Hansen stated: >> What would have prevented a state level actor from activating this >> exploit on a wide level during a time when it would have been most >> effective for them? > >A nation-state with a professional intelligence service probably isn't >very interested in taking down the keyserver network. Why should they >take down something that's not a big priority for them, especially if >it'll cost them a lot of international goodwill if it gets attributed >to them? I seriously doubt that a nation, such as North Korea or China, a nation that openly runs over its own citizens, would much care what anyone thought. However, I do agree with your general premise. >This has all the hallmarks of a child playing with matches and clapping >with glee as the house catches fire. While that is probably correct, it could also be attributed to some intelligence agency trying to test a 'proof of concept' in the real world in real time. Never-the-less, I think that Ockham's Razor applies here. -- Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From gnupg at eckner.net Sun Jun 30 16:07:52 2019 From: gnupg at eckner.net (Erich Eckner) Date: Sun, 30 Jun 2019 16:07:52 +0200 (CEST) Subject: SKS Keyserver Network Under Attack In-Reply-To: <3c41fbc2-4862-289d-d0ed-8ff3484ea98b@andrewg.com> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <3c41fbc2-4862-289d-d0ed-8ff3484ea98b@andrewg.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sun, 30 Jun 2019, Andrew Gallagher wrote: > On 2019/06/30 11:49, Mirimir via Gnupg-users wrote: >> It would stop when certs can no longer be poisoned. And I don't see the >> downside. I mean, what good does it do to have people downloading keys >> that break their stuff? >> >> I don't see that as "doing the bad guys? work for them". I see it as >> preventing bad guys escalating from hurting a few people to doing >> serious damage. That's not "punishing the victim". > > It prevents escalation, yes. But at the expense of exiling the targeted > people from the network - which may well be the attacker's real intent. > > Any "solution" that turns a general problem into a problem for a small > number of *specific individuals* is not a solution, it's a lynching. I'm > sure those specific individuals will be thankful that they've been > thrown under the bus for the greater good. I'm sure nobody else will be > looking over their shoulder wondering whether they'll be next. > > We solve this issue for *everyone*, or we all go home. > > -- > Andrew Gallagher > > Hi, maybe I don't get the original idea - but I thought, it was to block *uploads/updates* which would poisson a certificate - not to blackhole them after they got poissoned? cheers, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl0YwjkACgkQCu7JB1Xa e1ozlA/+O7leg3qYlW1KO8+z1cE2IDe03CDUYX1PovzIpbxSiSYREEqbcJJkelqv Bp1h8LZKUZuRNYIHD7NbFYMSUMaJTpI6S1p3stN214cK5vqY01x6ncEMvtpHJTGK /87VtN+g+9qch59lCAZMjOrVtrgW0R5AqCsjIisPFAPyAHjNYF+EjQ5xQkYfVq35 ny4TJXjSBjCzFO8+OcUW5ThHGwIq5CL6CW5PFmPDtkzIdI/yPowq20BWHz/AGiSq uxe32hKyJXNABe0Ow73NB4IOK8GrlGuUs2WAoMDKfQaBdNNguqgf8rSP52BLhtUT wY1xI2f/6mpi7Ygrwqnw6kIHEvhFAVR5T3KobLERn7B9uiXlBAp+PVIc/QDuPFG5 dVMgBacuGdXXM+dpjGKYbDVi1WYVr5JyqeJwNOiC/0fyNgO69HQGmSPPsFFauo9s i2pbVO/cv9X/aF9KLCcBbMP/nKHokLnShU3xAoIinFdGHN68iFVCPGlQhLwGlpMN 0Xq52TVjlpwt8OtEak0GIPhdyXQQkLrZnsDc2sB6s99u8R0L78KFoWAorvTDP9Hb o8+rz93AZxiObn9q2iTKYve0tWLuvTUTiTmgd42I2qFLNIfGLQCBtkqpcgBje4AK S6mrCP8AMrdhO3bOU1bdarN4FEonV6DUHAk8aMiqbwp1quAyHaw= =+Lsx -----END PGP SIGNATURE----- From peter at digitalbrains.com Sun Jun 30 17:33:37 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 30 Jun 2019 17:33:37 +0200 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: > "Look, this one guy who just got mugged? [...] I had to read it twice to distill what I think Mirimir meant, but I think they meant that if you blacklist/blackhole all affected certificates, you remove the incentive for the attackers to poison more certificates since the poison can't spread to the people fetching keys. Thus stopping the attackers. I concluded that Mirimir perhaps forgot about that this creates a second attack model, where you can block keys from being on the keyserver. This seems like a new problem that means this stopgap measure is probably not the one we want, since it still provides the incentive for attackers to poison keys. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Sun Jun 30 17:55:53 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 30 Jun 2019 16:55:53 +0100 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <3c41fbc2-4862-289d-d0ed-8ff3484ea98b@andrewg.com> Message-ID: > On 30 Jun 2019, at 15:07, Erich Eckner via Gnupg-users wrote: > > maybe I don't get the original idea - but I thought, it was to block *uploads/updates* which would poisson a certificate - not to blackhole them after they got poissoned? Hm, that?s not how I read it, although I could be wrong. It is possible to prevent submission of bad keys, but this just leads to new problems: 1. We would have to ensure that all keyservers block the same uploads. One permissive keyserver is a backdoor into the entire system. We can?t block bad keys at reconciliation time for the same reasons that have been hashed to death already. 2. Although it may be possible to block an individual upload of tens of thousands of key packets, it will not in general be possible to prevent an attacker from incrementally increasing the number of packets attached to a key over time. If we impose a reasonable limit on the cumulative number of packets attached to a key, that key may never become undownloadable, but it will at some point become unmodifiable - so we have just transformed one DOS vector into a different one. A From konstantin at linuxfoundation.org Sun Jun 30 18:54:57 2019 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Sun, 30 Jun 2019 12:54:57 -0400 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: <20190630165457.GB13925@chatter.i7.local> On Sun, Jun 30, 2019 at 03:49:55AM -0700, Mirimir via Gnupg-users wrote: >> c) what happens when they go after more certificates? >> >> If you're willing to blackhole two certs, great. Where does it stop? >> How many certs can the strong set stand to lose? > >Your third point is actually why I suggested this. Maybe I'm just >twisted, but what if some dickhead goes after certs that would break >stuff for millions of people? One might, for example, block Linux kernel >maintenance and development. Maybe just before using some 0-day. I highly doubt this would be effective, mainly because I don't think anyone on the kernel development side of things runs keyring refreshes in any routine fashion -- if ever. For those relying on PGP to verify downloaded releases, we provide WKD lookups (https://www.kernel.org/signature.html). This whole thing *will* probably push me towards setting up a Hagrid instance, especially if we can teach it to compare submissions against an allow-list. Not sure what I'm going to do about the whole "web of trust" side of things, though. I *really* don't like the idea of setting up any kind of certification/trust authority. -K From dkg at fifthhorseman.net Sun Jun 30 19:06:25 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 30 Jun 2019 13:06:25 -0400 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> Message-ID: <87o92fngtq.fsf@fifthhorseman.net> On Sun 2019-06-30 00:33:22 +0100, Andrew Gallagher wrote: > Indeed, c) was exactly the killer use case I had in mind. so, how do we get there? > On the other hand, b) is also quite useful in the short to medium > term, until all mail providers decide to support WKD etc. WKD is mighty nice, but it is not necessary. For example, if you don't care about first-contact, Autocrypt is a totally reasonable key discovery mechanism. It also has a significantly reduced metadata footprint compared to WKD or DANE OPENPGPKEY, since all messaging is in-band. It has other problems, of course, but it can be used directly today (not just "short to medium term"). > And considering that some companies still don?t fully support PGP/MIME > after nearly twenty years of being the preferred standard (I?m looking > at you, Apple), ?short to medium? effectively means ?indefinitely?. If you know something specific about Apple failing PGP/MIME in some capacity i hope you'll be more explicit about it, because i don't know what you're talking about. > So maybe we shouldn?t think of keyservers as storage repositories, but > rather as search engines. The keyservers should not be authoritative, > but they should be a best effort directory of where the authoritative > locations are, combined with a cache of the non-identity cryptographic > material in case the authoritative locations get DOSed. Of course they're both search engines and storage rpositories, and they are not and have never been authoritative. Anyone who claimed keyservers were authoritative in the past was either confused or misleading you. > If the authoritative location is not on a keyserver, then we do not > need to sync arbitrary data between keyservers, just a list of > location hints. The keyservers would then fetch from the authoritative > locations and decide for themselves how much of the content to cache. i'd be curious to read any specific guidance about how you think a sensible keyserver would make those decisions. If you want to propose changes to https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore i'd be happy to incorporate them too. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gnupg at leo.gaspard.ninja Sun Jun 30 19:37:56 2019 From: gnupg at leo.gaspard.ninja (Leo Gaspard) Date: Sun, 30 Jun 2019 19:37:56 +0200 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <3c41fbc2-4862-289d-d0ed-8ff3484ea98b@andrewg.com> Message-ID: <875zon0ya3.fsf@llwynog.ekleog.org> > 1. We would have to ensure that all keyservers block the same > uploads. One permissive keyserver is a backdoor into the entire > system. We can?t block bad keys at reconciliation time for the same > reasons that have been hashed to death already. One way to do that, though it would mean officially sunsetting SKS, might be to: 1. Publish an update to SKS that: - Blocks all uploads of any packet that is not a revocation signature packet (maybe also having to check the revocation is actually correctly signed, to avoid flooding of revocation packets to become the new flaw) - Embeds a hardcoded list of already-disrupted keys for which packets should be filtered-out when serving them 2. Pressure keyserver operators into updating 3. Kick all not-up-to-date keyservers from the pool after some delay deemed acceptable (shorter means less broken GnuPG, longer means less keyservers kicked out) Note: I do not know how the pool is handled. Maybe this would mean that the new update to SKS would need to stop synchronizing with earlier versions, and that the hkps pool should be turned off until enough keyservers are updated to handle the load? Do you think such a plan might be reasonably done, to at least keep the most basic functionality of not breaking existing installations and allow them to keep revocations flowing? The biggest issue I can see is it requires a quite big amount of development work. Hope that helps, Leo From david at gbenet.com Sun Jun 30 20:18:47 2019 From: david at gbenet.com (David) Date: Sun, 30 Jun 2019 19:18:47 +0100 Subject: Your Thoughts Message-ID: Your Thoughts :) https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! https://gbenet.com From guilhem at fripost.org Sun Jun 30 20:56:03 2019 From: guilhem at fripost.org (Guilhem Moulin) Date: Sun, 30 Jun 2019 20:56:03 +0200 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> Message-ID: <20190630185603.GA17531@fripost.org> On Sun, 30 Jun 2019 at 00:36:19 -0700, Mirimir via Gnupg-users wrote: > | High-risk users should stop using the keyserver network immediately. > > So OK, I can purge requests to SKS keyservers from my machines. But what > about upstream impacts? As I understand it, GnuPG authentication is > pervasive. And I suspect that getting missing keys from SKS is common. > As an error trap, if nothing else. Third-party signatures from locally unknown certificates are arguably not so useful, so how about using ?--keyserver-options import-clean?? (Or even making it the default behavior?) Of course it's not perfect as it still clutters network traffic and gpg(1) needs to clean up the mess client-side (which is slow and CPU expensive), but at least it mitigates the DoS attack: it doesn't prevent keyring updates, and limits the bloat on disk. Compare ~$ export GNUPGHOME="$(mktemp --tmpdir=/dev/shm --directory)" ~$ alias time="command time -f '%E (%U user, %S sys) %P CPU %Mk maxres'" ~$ gpg --import /usr/share/keyrings/*.gpg ~$ gpg --with-colons --list-sigs | grep -c ^pub: 1187 ~$ gpg --with-colons --list-sigs | grep -c ^sig: 56001 ~$ stat -c %s "$GNUPGHOME/pubring.kbx" 34041308 ~$ time gpg --recv-keys \ C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 \ CC11BE7CBBED77B120F37B011DCBDC01B44427C7 gpg: key 1DCBDC01B44427C7: 149109 signatures not checked due to missing keys gpg: error writing keyring '?/pubring.kbx': Provided object is too large gpg: key F20691179038E5C6: 54608 signatures not checked due to missing keys gpg: error writing keyring '?/pubring.kbx': Provided object is too large [?] Command exited with non-zero status 2 10:53.44 (269.47 user, 362.81 sys) 96% CPU 330976k maxres (which fails the keyring update operation) with [?] ~$ time gpg --keyserver-options import-clean --recv-keys \ C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 \ CC11BE7CBBED77B120F37B011DCBDC01B44427C7 gpg: key 1DCBDC01B44427C7: 1 duplicate signature removed gpg: key 1DCBDC01B44427C7: 1 signature reordered gpg: key 1DCBDC01B44427C7: public key "Robert J. Hansen " imported gpg: key F20691179038E5C6: 2 duplicate signatures removed gpg: key F20691179038E5C6: 2 signatures reordered gpg: key F20691179038E5C6: "Daniel Kahn Gillmor " not changed gpg: no ultimately trusted keys found gpg: Total number processed: 2 gpg: imported: 1 gpg: unchanged: 1 49:48.80 (1668.47 user, 1305.03 sys) 99% CPU 190840k maxres (The initial import of /usr/share/keyrings/*.gpg is merely there to start with a non-trivial keyring. In particular, a keyring containing certificates that issued third-party signatures on 1DCBDC01B44427C7 and F20691179038E5C6. The keyring even contains a non-poisoned version of dkg's key, as on my system the glob matches ?/usr/share/keyrings/debian-keyring.gpg?.) I suppose validating keyservers are the way to go, but it seems like there is currently no good solution for third-party signatures. For workflow relying on these (at least for locally known signers), or which for some other reason need to stick to SKS, a possible mitigation is to pass `--keyserver-options import-clean`. As seen above refreshing the keyring might take a veeery long time (possibly room for improvement, from an algorithmic perspective I don't get why filtering signature packets from unknown signers is so slow), but at least succeeds in getting updates from SKS. -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From abbot at monksofcool.net Sun Jun 30 22:01:32 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Sun, 30 Jun 2019 22:01:32 +0200 Subject: Your Thoughts In-Reply-To: References: Message-ID: <87d0iuonab.fsf@ra.horus-it.com> * david at gbenet.com: > Your Thoughts :) I think the article is five years old, has not aged well (e.g. MUA integration has improved), and that nothing better than PGP has come along in the meantime. Next. ;-) -Ralph