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: <F8A04EC8-4F20-4543-946C-87B2F0CA80E4@gmail.com>

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 <rjh at sixdemonbag.org> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190531/a790ae94/attachment-0001.html>

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: <F8A04EC8-4F20-4543-946C-87B2F0CA80E4@gmail.com>
References: <2849561439a8a908889eaa2f3f7a5e5f@smtp.hushmail.com>
 <8b66ae97-1117-8ead-3aea-4778b6706aa7@sixdemonbag.org>
 <F8A04EC8-4F20-4543-946C-87B2F0CA80E4@gmail.com>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190601/ed347f4e/attachment.sig>

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 <wolfgang.traylor at posteo.de> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190601/27b82097/attachment.bin>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190601/ea130d9e/attachment-0001.sig>

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 <wolfgang.traylor at posteo.de> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190601/b434cfa9/attachment.bin>

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>
 <a1e51e4f-b664-50ed-f3de-630737e00853@gmail.com>
 <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) <chip at senkbeil.org>
> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190603/d4df17ef/attachment.sig>

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: <lqLSVXFmqenNMRnONjm5TpTfhEpHeMHaVzKW24j7LA8x02Vx4WhfwY7GWI9ffyOUQEXJRduJD_tFMXVoMVm9BU2ehPKQiXHerag83B3CYwg=@protonmail.com>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190603/bd97f8e9/attachment.html>

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: <lqLSVXFmqenNMRnONjm5TpTfhEpHeMHaVzKW24j7LA8x02Vx4WhfwY7GWI9ffyOUQEXJRduJD_tFMXVoMVm9BU2ehPKQiXHerag83B3CYwg=@protonmail.com>
References: <lqLSVXFmqenNMRnONjm5TpTfhEpHeMHaVzKW24j7LA8x02Vx4WhfwY7GWI9ffyOUQEXJRduJD_tFMXVoMVm9BU2ehPKQiXHerag83B3CYwg=@protonmail.com>
Message-ID: <bb434bb6-8a92-5980-65a7-09ec17da656c@sixdemonbag.org>

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: <Cm4Ky1IFc5HUh9p5v17zJC7hhW3LNhWVt-kESQUpk0XnCA00sHjhC0iMOIx3ygMzN8A8Tm0b4n4kJoMccdOpHzCRgS5G-s64U7oRNTIX3Y0=@protonmail.com>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190603/57165e1b/attachment.html>

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>
 <a1e51e4f-b664-50ed-f3de-630737e00853@gmail.com>
 <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) <chip at senkbeil.org>
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) <chip at senkbeil.org>
> > 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: <Cm4Ky1IFc5HUh9p5v17zJC7hhW3LNhWVt-kESQUpk0XnCA00sHjhC0iMOIx3ygMzN8A8Tm0b4n4kJoMccdOpHzCRgS5G-s64U7oRNTIX3Y0=@protonmail.com>
References: <Cm4Ky1IFc5HUh9p5v17zJC7hhW3LNhWVt-kESQUpk0XnCA00sHjhC0iMOIx3ygMzN8A8Tm0b4n4kJoMccdOpHzCRgS5G-s64U7oRNTIX3Y0=@protonmail.com>
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
<mid:Cm4Ky1IFc5HUh9p5v17zJC7hhW3LNhWVt-kESQUpk0XnCA00sHjhC0iMOIx3ygMzN8A8Tm0b4n4kJoMccdOpHzCRgS5G-s64U7oRNTIX3Y0=@protonmail.com>,
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                  <mailto:2017-r3sgs86x8e-lists-groups at riseup.net>

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: <c7f71634-7ae7-f43f-e29b-7800931b4c0f@metacode.biz>

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: <CAADKO3uXxF78x_FBDqJX9ekkqjT+b3gMb7jh_XYvnhMw6jU0ag@mail.gmail.com>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190607/bb21f003/attachment.html>

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: <CAADKO3uXxF78x_FBDqJX9ekkqjT+b3gMb7jh_XYvnhMw6jU0ag@mail.gmail.com>
References: <CAADKO3uXxF78x_FBDqJX9ekkqjT+b3gMb7jh_XYvnhMw6jU0ag@mail.gmail.com>
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: <CACpG-68_LnLoHcO3hc0-BvYwBQg_Zo3BHU0YSEwo=JiF6JRMqg@mail.gmail.com>

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 <gcrypt.h>
# include <stdio.h>
# include <string.h>
# include <stdlib.h>
# include <gpg-error.h>

# 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190608/d9536a5d/attachment-0001.html>

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>
 <dbb78879-9e1a-e010-4183-11e1ef770338@runbox.com>
 <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org>
 <f79e3914-c6ff-04d1-45d1-01f5284e2c69@runbox.com>
 <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: <mailman.19.1559982355.30378.gnupg-users@gnupg.org>

Christopher W. Richardson wrote:

> 
> 
> > On 9 May 2019, at 22:34, Stefan Claas <sac at 300baud.de> wrote:
> > 
> > Am Wed, 8 May 2019 22:08:22 +0200
> > schrieb Christopher W. Richardson <cwr at cwrichardson.com>:
> > 
> >>> On 6 May 2019, at 16:15, Stefan Claas <sac at 300baud.de
> >>> <mailto:sac at 300baud.de>> 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>
 <dbb78879-9e1a-e010-4183-11e1ef770338@runbox.com>
 <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org>
 <f79e3914-c6ff-04d1-45d1-01f5284e2c69@runbox.com>
 <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 <sac at 300baud.de> wrote:
>>>
>>> Am Wed, 8 May 2019 22:08:22 +0200
>>> schrieb Christopher W. Richardson <cwr at cwrichardson.com>:
>>>
>>>>> On 6 May 2019, at 16:15, Stefan Claas <sac at 300baud.de
>>>>> <mailto:sac at 300baud.de>> 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>
 <dbb78879-9e1a-e010-4183-11e1ef770338@runbox.com>
 <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org>
 <f79e3914-c6ff-04d1-45d1-01f5284e2c69@runbox.com>
 <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: <mailman.20.1560068446.30378.gnupg-users@gnupg.org>

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: <dd81eeb5-5536-f4c8-f603-de471934e95f@metacode.biz>

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: <mailman.21.1560071743.30378.gnupg-users@gnupg.org>

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>
 <dbb78879-9e1a-e010-4183-11e1ef770338@runbox.com>
 <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org>
 <f79e3914-c6ff-04d1-45d1-01f5284e2c69@runbox.com>
 <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: <mailman.22.1560082444.30378.gnupg-users@gnupg.org>

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: <c7f71634-7ae7-f43f-e29b-7800931b4c0f@metacode.biz>
References: <c7f71634-7ae7-f43f-e29b-7800931b4c0f@metacode.biz>
Message-ID: <20190609121608.GA5982@pc21.mareichelt.com>

* Wiktor Kwapisiewicz via Gnupg-users <gnupg-users at gnupg.org> 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>
 <dbb78879-9e1a-e010-4183-11e1ef770338@runbox.com>
 <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org>
 <f79e3914-c6ff-04d1-45d1-01f5284e2c69@runbox.com>
 <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: <c7f71634-7ae7-f43f-e29b-7800931b4c0f@metacode.biz>
 <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 <test at example.com>" 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>
 <dbb78879-9e1a-e010-4183-11e1ef770338@runbox.com>
 <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org>
 <f79e3914-c6ff-04d1-45d1-01f5284e2c69@runbox.com>
 <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: <mailman.23.1560102281.30378.gnupg-users@gnupg.org>

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>
 <dbb78879-9e1a-e010-4183-11e1ef770338@runbox.com>
 <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org>
 <f79e3914-c6ff-04d1-45d1-01f5284e2c69@runbox.com>
 <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: <mailman.24.1560102682.30378.gnupg-users@gnupg.org>

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: <CAADKO3uXxF78x_FBDqJX9ekkqjT+b3gMb7jh_XYvnhMw6jU0ag@mail.gmail.com>
References: <CAADKO3uXxF78x_FBDqJX9ekkqjT+b3gMb7jh_XYvnhMw6jU0ag@mail.gmail.com>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190609/e5b93f5e/attachment.sig>

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>
 <dbb78879-9e1a-e010-4183-11e1ef770338@runbox.com>
 <9d8eb962c72e9b90a4dea34d3d2035b6c5eae89e.camel@gentoo.org>
 <f79e3914-c6ff-04d1-45d1-01f5284e2c69@runbox.com>
 <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: <mailman.25.1560178333.30378.gnupg-users@gnupg.org>

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: <CACpG-68ugXHSRA7dTga-OuL=h2yFoHE=91zCx5BRqH+DTYj50g@mail.gmail.com>

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 <gcrypt.h>
# include <stdio.h>
# include <string.h>
# include <stdlib.h>
# include <gpg-error.h>

# 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190612/2967e4fb/attachment.html>

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: <CACpG-68ugXHSRA7dTga-OuL=h2yFoHE=91zCx5BRqH+DTYj50g@mail.gmail.com>
 (Hassan Mostafa's message of "Wed, 12 Jun 2019 10:08:01 +0200")
References: <CACpG-68ugXHSRA7dTga-OuL=h2yFoHE=91zCx5BRqH+DTYj50g@mail.gmail.com>
Message-ID: <87sgsdr4si.fsf@wheatstone.g10code.de>

Hi!

On Wed, 12 Jun 2019 10:08, hassan.mostafa87 at gmail.com said:
> # include <gpg-error.h>
>
> # 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190613/28076ed5/attachment.sig>

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: <AM0PR05MB4867104CCE089F383DE4D84B9EEF0@AM0PR05MB4867.eurprd05.prod.outlook.com>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190613/a954e089/attachment.html>

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   - .-..   <https://keybase.io/tlikonen> //
// 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190614/0a10d8a5/attachment.sig>

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: <fd20ca89-b65f-ef03-aea4-008057d166c7@andrewg.com>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190614/4b62307b/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190614/566f9435/attachment-0001.sig>

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: <mailman.26.1560520956.30378.gnupg-users@gnupg.org>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190614/6f4bf850/attachment.sig>

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   <https://github.com/tlikonen> //
// PGP: 4E1055DC84E9DFF613D78557719D69D324539450 ///
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190614/249828e4/attachment.sig>

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: <mailman.27.1560522820.30378.gnupg-users@gnupg.org>

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: <BUULDVME8UMZ.16DDFWUTXGJTE@gluon>

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: <fd20ca89-b65f-ef03-aea4-008057d166c7@andrewg.com>
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: <mailman.28.1560672040.30378.gnupg-users@gnupg.org>

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 <look at my.amazin.horse> 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 <look at my.amazin.horse> 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: <mailman.29.1560694242.30378.gnupg-users@gnupg.org>

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: <mailman.7496.1541363170.30381.gnupg-users@gnupg.org>
 <67FD4C95-95EE-4A9D-B05C-8F567D849639@cleanfuels.nl>
 <054ed41f-adc4-737b-0858-8c6f7a9c70fd@metacode.biz>
 <d6b72b6f-6bad-26ca-6de3-b42a15606b13@gmail.com>
 <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: <robbat2-20190616T231830-180981258Z@orbis-terrarum.net>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190616/a9ab4401/attachment.sig>

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: <ba880847-25ca-8943-69bd-009a4428ed2c@enigmail.net>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190618/607b842e/attachment.sig>

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: <CABGOUcxBtOaCGLKSGr88gKfgTVzqXbKX0ZVKy1zdr_-OPZyPqA@mail.gmail.com>

On Fri, Jun 14, 2019 at 7:35 AM Stefan Claas <sac at 300baud.de> 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: <CAC62LX7d7V2q7a9T4hkDmxYJ10N_ktoJx_ESAuRNXKmsCH1PrA@mail.gmail.com>

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) <fernan.aguero at gmail.com>"
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190619/57a070fd/attachment.html>

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: <CALLGG_Jp6pbE7x_jFFpnOHULe41AUS-kwBCrHThxEFf9-cqPug@mail.gmail.com>

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: <LhmOjpY--3-1@tuta.io>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190620/a9ba30f1/attachment.html>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190621/fb37887c/attachment.sig>

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: <CABGOUcxBtOaCGLKSGr88gKfgTVzqXbKX0ZVKy1zdr_-OPZyPqA@mail.gmail.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>
 <CABGOUcxBtOaCGLKSGr88gKfgTVzqXbKX0ZVKy1zdr_-OPZyPqA@mail.gmail.com>
Message-ID: <fa9b0978-9927-0456-5c09-504b5c78dcdd@bruckner.tk>

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 <sac at 300baud.de> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190621/dc24e4e5/attachment.bin>

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: <fa9b0978-9927-0456-5c09-504b5c78dcdd@bruckner.tk>
References: <fa9b0978-9927-0456-5c09-504b5c78dcdd@bruckner.tk>
 <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>
 <CABGOUcxBtOaCGLKSGr88gKfgTVzqXbKX0ZVKy1zdr_-OPZyPqA@mail.gmail.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."
 <fa9b0978-9927-0456-5c09-504b5c78dcdd@bruckner.tk>
Message-ID: <201906211138.x5LBbsQ3087089@fire.js.berklix.net>

> From:		Juergen Bruckner via Gnupg-users <gnupg-users at gnupg.org>
> 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/<UID>.  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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190621/1246ea7a/attachment.sig>

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: <fa9b0978-9927-0456-5c09-504b5c78dcdd@bruckner.tk> (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>
 <CABGOUcxBtOaCGLKSGr88gKfgTVzqXbKX0ZVKy1zdr_-OPZyPqA@mail.gmail.com>
 <fa9b0978-9927-0456-5c09-504b5c78dcdd@bruckner.tk>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190621/ba52f213/attachment.sig>

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>
 <CABGOUcxBtOaCGLKSGr88gKfgTVzqXbKX0ZVKy1zdr_-OPZyPqA@mail.gmail.com>
 <fa9b0978-9927-0456-5c09-504b5c78dcdd@bruckner.tk>
 <87fto3oyhj.fsf@wheatstone.g10code.de>
Message-ID: <mailman.30.1561124986.30378.gnupg-users@gnupg.org>

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>
 <CABGOUcxBtOaCGLKSGr88gKfgTVzqXbKX0ZVKy1zdr_-OPZyPqA@mail.gmail.com>
 <fa9b0978-9927-0456-5c09-504b5c78dcdd@bruckner.tk>
 <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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190621/baf4831c/attachment.sig>

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/<UID>.  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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190621/c73acf02/attachment-0001.sig>

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) <jennifer.mead at pacificorp.com>
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) <jennifer.mead at pacificorp.com>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190621/804dfa5a/attachment.html>

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>
 <CABGOUcxBtOaCGLKSGr88gKfgTVzqXbKX0ZVKy1zdr_-OPZyPqA@mail.gmail.com>
 <fa9b0978-9927-0456-5c09-504b5c78dcdd@bruckner.tk>
 <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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190621/f64c60b2/attachment.sig>

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 <KEYID>` 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190622/29405c49/attachment-0001.bin>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190622/4cf975a7/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190622/92471077/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190623/19afc91c/attachment.sig>

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: <sig.0077d8a474.60318319-0345-f1e3-fa12-cd39481ad549@sohnen-moe.com>

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
<https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/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: <sig.0077d8a474.60318319-0345-f1e3-fa12-cd39481ad549@sohnen-moe.com>
References: <sig.0077d8a474.60318319-0345-f1e3-fa12-cd39481ad549@sohnen-moe.com>
Message-ID: <sig.1077149e64.d5f0c62a-6435-961e-49c1-a48ed1bcc0b9@sohnen-moe.com>

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: <a60355e12364fb7f434309f6e2f5858b6f252afd.camel@googlemail.com>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190625/1ed09a2a/attachment.sig>

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: <fcb8423713ff63b2f0c3c6f57d4bb0d04fe1eee4.camel@googlemail.com>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190625/f9b4717f/attachment-0001.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190625/0a43b813/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190625/d4f41b2e/attachment.sig>

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: <CALLGG_Jp6pbE7x_jFFpnOHULe41AUS-kwBCrHThxEFf9-cqPug@mail.gmail.com>
References: <20190617135821.GA1297@osboxes>
 <CALLGG_Jp6pbE7x_jFFpnOHULe41AUS-kwBCrHThxEFf9-cqPug@mail.gmail.com>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190625/8d8e13a9/attachment.sig>

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: <fcb8423713ff63b2f0c3c6f57d4bb0d04fe1eee4.camel@googlemail.com>
References: <20190621112017.GA2077@c720-r349041>
 <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041>
 <874l4ioydb.fsf@wheatstone.g10code.de> <20190623102134.GA1923@c720-r349041>
 <fcb8423713ff63b2f0c3c6f57d4bb0d04fe1eee4.camel@googlemail.com>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190625/1302667a/attachment.sig>

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: <c7f71634-7ae7-f43f-e29b-7800931b4c0f@metacode.biz>
 <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 <test at example.com>" 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190625/4df51dad/attachment.sig>

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: <sig.1077149e64.d5f0c62a-6435-961e-49c1-a48ed1bcc0b9@sohnen-moe.com>
References: <sig.0077d8a474.60318319-0345-f1e3-fa12-cd39481ad549@sohnen-moe.com>
 <sig.1077149e64.d5f0c62a-6435-961e-49c1-a48ed1bcc0b9@sohnen-moe.com>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190625/29f69c98/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190625/4d63888e/attachment-0001.sig>

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>
 <fcb8423713ff63b2f0c3c6f57d4bb0d04fe1eee4.camel@googlemail.com>
 <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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190625/a8e3933e/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190625/e21e752a/attachment.sig>

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: <sig.0077d8a474.60318319-0345-f1e3-fa12-cd39481ad549@sohnen-moe.com>
 <sig.1077149e64.d5f0c62a-6435-961e-49c1-a48ed1bcc0b9@sohnen-moe.com>
 <87blylwulg.fsf@fifthhorseman.net>
Message-ID: <sig.007919c151.da55779d-2161-7882-9ef0-39a6a87f680b@sohnen-moe.com>

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: <sig.007919c151.da55779d-2161-7882-9ef0-39a6a87f680b@sohnen-moe.com>
References: <sig.0077d8a474.60318319-0345-f1e3-fa12-cd39481ad549@sohnen-moe.com>
 <sig.1077149e64.d5f0c62a-6435-961e-49c1-a48ed1bcc0b9@sohnen-moe.com>
 <87blylwulg.fsf@fifthhorseman.net>
 <sig.007919c151.da55779d-2161-7882-9ef0-39a6a87f680b@sohnen-moe.com>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190625/aa007d49/attachment.sig>

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: <sig.0077d8a474.60318319-0345-f1e3-fa12-cd39481ad549@sohnen-moe.com>
 <sig.1077149e64.d5f0c62a-6435-961e-49c1-a48ed1bcc0b9@sohnen-moe.com>
 <87blylwulg.fsf@fifthhorseman.net>
 <sig.007919c151.da55779d-2161-7882-9ef0-39a6a87f680b@sohnen-moe.com>
 <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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190625/f59a6159/attachment.sig>

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: <sig.0077d8a474.60318319-0345-f1e3-fa12-cd39481ad549@sohnen-moe.com>
 <sig.1077149e64.d5f0c62a-6435-961e-49c1-a48ed1bcc0b9@sohnen-moe.com>
 <87blylwulg.fsf@fifthhorseman.net>
 <sig.007919c151.da55779d-2161-7882-9ef0-39a6a87f680b@sohnen-moe.com>
 <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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190626/09387c80/attachment-0001.sig>

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>
 <fcb8423713ff63b2f0c3c6f57d4bb0d04fe1eee4.camel@googlemail.com>
 <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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190626/00c9ae4d/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190626/a4d62e9c/attachment.sig>

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: <mailman.31.1561537186.30378.gnupg-users@gnupg.org>

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: <mailman.32.1561538768.30378.gnupg-users@gnupg.org>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190626/bd63cd17/attachment.key>

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: <c86561d58f1b46fd96ec2130b539bca8@svw-exmb2.unifr.ch>

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>
 <fcb8423713ff63b2f0c3c6f57d4bb0d04fe1eee4.camel@googlemail.com>
 <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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190626/ba8374fb/attachment.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190626/e2a1a31e/attachment.html>

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>
 <CALLGG_Jp6pbE7x_jFFpnOHULe41AUS-kwBCrHThxEFf9-cqPug@mail.gmail.com>
 <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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190628/1e1fbefa/attachment.sig>

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>
 <fcb8423713ff63b2f0c3c6f57d4bb0d04fe1eee4.camel@googlemail.com>
 <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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190628/ccd57dfc/attachment.sig>

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: <c03aeac2-9952-7a82-19fe-3f187b2806c8@schokokeks.org>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190628/3da4379d/attachment.sig>

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: <c03aeac2-9952-7a82-19fe-3f187b2806c8@schokokeks.org>
References: <20190621112017.GA2077@c720-r349041>
 <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041>
 <874l4ioydb.fsf@wheatstone.g10code.de> <20190623102134.GA1923@c720-r349041>
 <c03aeac2-9952-7a82-19fe-3f187b2806c8@schokokeks.org>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190628/5c6c41fb/attachment.sig>

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>
 <c03aeac2-9952-7a82-19fe-3f187b2806c8@schokokeks.org>
 <87ftnup18e.fsf@fifthhorseman.net>
Message-ID: <ce7abacc-a79b-b1a1-d53c-3f0ee53e1634@schokokeks.org>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190628/8d916b8b/attachment-0001.sig>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190628/f698af28/attachment.sig>

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: <ce7abacc-a79b-b1a1-d53c-3f0ee53e1634@schokokeks.org>
References: <20190621112017.GA2077@c720-r349041>
 <87muibozcm.fsf@wheatstone.g10code.de> <20190621163938.GA2175@c720-r349041>
 <874l4ioydb.fsf@wheatstone.g10code.de> <20190623102134.GA1923@c720-r349041>
 <c03aeac2-9952-7a82-19fe-3f187b2806c8@schokokeks.org>
 <87ftnup18e.fsf@fifthhorseman.net>
 <ce7abacc-a79b-b1a1-d53c-3f0ee53e1634@schokokeks.org>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190628/e717dd0e/attachment.sig>

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>
 <c03aeac2-9952-7a82-19fe-3f187b2806c8@schokokeks.org>
 <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: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>

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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190629/87b42ab1/attachment.html>

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: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
Message-ID: <mailman.33.1561835425.30378.gnupg-users@gnupg.org>

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>
 <CABGOUcxBtOaCGLKSGr88gKfgTVzqXbKX0ZVKy1zdr_-OPZyPqA@mail.gmail.com>
 <fa9b0978-9927-0456-5c09-504b5c78dcdd@bruckner.tk>
 <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 <dkg at fifthhorseman.net> 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: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
Message-ID: <hXtQqRdToFAQtiwhmtSyvGoeuB2kRsBS0yBUrfjcyl1QX4haFJFe9jz4nXKBeaH5U2vfgcfEvX_D740yWIt75jxryysw3kro3SQiRHcj6XQ=@digicana.com>

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 <ryan at digicana.com> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190630/504e08ac/attachment.html>

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: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
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: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
Message-ID: <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>

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: <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
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: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
Message-ID: <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>


> On 30 Jun 2019, at 09:19, Robert J. Hansen <rjh at sixdemonbag.org> 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: <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
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: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
 <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: <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
Message-ID: <bec30f0b-c20d-5e5c-08aa-d7b6f9f888a8@riseup.net>

On 06/30/2019 01:34 AM, Andrew Gallagher wrote:
> 
>> On 30 Jun 2019, at 09:19, Robert J. Hansen <rjh at sixdemonbag.org> 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: <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
Message-ID: <mailman.34.1561886655.30378.gnupg-users@gnupg.org>

Andrew Gallagher wrote:

> 
> > On 30 Jun 2019, at 09:19, Robert J. Hansen <rjh at sixdemonbag.org> 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: <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
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: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
 <3c238171-9818-c336-81fd-fa0776efedbe@sixdemonbag.org>
Message-ID: <mailman.35.1561888240.30378.gnupg-users@gnupg.org>

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>
 <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
 <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: <bec30f0b-c20d-5e5c-08aa-d7b6f9f888a8@riseup.net>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
 <bec30f0b-c20d-5e5c-08aa-d7b6f9f888a8@riseup.net>
Message-ID: <D65667D4-992A-4743-A20E-7619BBEABEA2@andrewg.com>


> On 30 Jun 2019, at 10:21, Mirimir via Gnupg-users <gnupg-users at gnupg.org> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190630/c43b948c/attachment-0001.html>

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>
 <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
 <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 <look at my.amazin.horse> 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: <D65667D4-992A-4743-A20E-7619BBEABEA2@andrewg.com>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
 <bec30f0b-c20d-5e5c-08aa-d7b6f9f888a8@riseup.net>
 <D65667D4-992A-4743-A20E-7619BBEABEA2@andrewg.com>
Message-ID: <bfa9ff70-10b7-1280-2a50-25520e18be93@sixdemonbag.org>

> 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: <bfa9ff70-10b7-1280-2a50-25520e18be93@sixdemonbag.org>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
 <bec30f0b-c20d-5e5c-08aa-d7b6f9f888a8@riseup.net>
 <D65667D4-992A-4743-A20E-7619BBEABEA2@andrewg.com>
 <bfa9ff70-10b7-1280-2a50-25520e18be93@sixdemonbag.org>
Message-ID: <fd59d544-d9b8-fc5a-1aab-f3b47082eccb@riseup.net>

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: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <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: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
Message-ID: <lrnN7VdTSkAZKTLLZOracrLNm3NegVRrVv8YrHDHcJ8zXvOooEtXlXEasLvjzgLsqFkvX5Y4DVQavGJemMwWac4ByCVgmsNL6syb0FDVO6Y=@digicana.com>

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 <rjh at sixdemonbag.org> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190630/fea4803a/attachment-0001.html>

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: <lrnN7VdTSkAZKTLLZOracrLNm3NegVRrVv8YrHDHcJ8zXvOooEtXlXEasLvjzgLsqFkvX5Y4DVQavGJemMwWac4ByCVgmsNL6syb0FDVO6Y=@digicana.com>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <lrnN7VdTSkAZKTLLZOracrLNm3NegVRrVv8YrHDHcJ8zXvOooEtXlXEasLvjzgLsqFkvX5Y4DVQavGJemMwWac4ByCVgmsNL6syb0FDVO6Y=@digicana.com>
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: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <lrnN7VdTSkAZKTLLZOracrLNm3NegVRrVv8YrHDHcJ8zXvOooEtXlXEasLvjzgLsqFkvX5Y4DVQavGJemMwWac4ByCVgmsNL6syb0FDVO6Y=@digicana.com>
 <45f2bc73-b2b2-80af-9649-2f21ae19d6bf@sixdemonbag.org>
Message-ID: <rVE_ZJygZO1f-s6FDZP-LJhXcAdU6IxWnYUlG5wfq3jsUltCEWAlkvg6i5PTGOZYfg6fcuhmE2VOIaMQjWPSL4EowioBOA3M544eO27CaOw=@digicana.com>

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 <rjh at sixdemonbag.org> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190630/cc01770d/attachment.html>

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: <rVE_ZJygZO1f-s6FDZP-LJhXcAdU6IxWnYUlG5wfq3jsUltCEWAlkvg6i5PTGOZYfg6fcuhmE2VOIaMQjWPSL4EowioBOA3M544eO27CaOw=@digicana.com>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <lrnN7VdTSkAZKTLLZOracrLNm3NegVRrVv8YrHDHcJ8zXvOooEtXlXEasLvjzgLsqFkvX5Y4DVQavGJemMwWac4ByCVgmsNL6syb0FDVO6Y=@digicana.com>
 <45f2bc73-b2b2-80af-9649-2f21ae19d6bf@sixdemonbag.org>
 <rVE_ZJygZO1f-s6FDZP-LJhXcAdU6IxWnYUlG5wfq3jsUltCEWAlkvg6i5PTGOZYfg6fcuhmE2VOIaMQjWPSL4EowioBOA3M544eO27CaOw=@digicana.com>
Message-ID: <c621e595-6c7c-5c13-b515-44ba34d66d9a@sixdemonbag.org>

> 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: <fd59d544-d9b8-fc5a-1aab-f3b47082eccb@riseup.net>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
 <bec30f0b-c20d-5e5c-08aa-d7b6f9f888a8@riseup.net>
 <D65667D4-992A-4743-A20E-7619BBEABEA2@andrewg.com>
 <bfa9ff70-10b7-1280-2a50-25520e18be93@sixdemonbag.org>
 <fd59d544-d9b8-fc5a-1aab-f3b47082eccb@riseup.net>
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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190630/6da748bf/attachment-0001.sig>

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: <fd59d544-d9b8-fc5a-1aab-f3b47082eccb@riseup.net>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
 <bec30f0b-c20d-5e5c-08aa-d7b6f9f888a8@riseup.net>
 <D65667D4-992A-4743-A20E-7619BBEABEA2@andrewg.com>
 <bfa9ff70-10b7-1280-2a50-25520e18be93@sixdemonbag.org>
 <fd59d544-d9b8-fc5a-1aab-f3b47082eccb@riseup.net>
Message-ID: <fe04bde9-cde5-add5-ca3d-c8c3f6819e78@sixdemonbag.org>

> 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: <c621e595-6c7c-5c13-b515-44ba34d66d9a@sixdemonbag.org>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <lrnN7VdTSkAZKTLLZOracrLNm3NegVRrVv8YrHDHcJ8zXvOooEtXlXEasLvjzgLsqFkvX5Y4DVQavGJemMwWac4ByCVgmsNL6syb0FDVO6Y=@digicana.com>
 <45f2bc73-b2b2-80af-9649-2f21ae19d6bf@sixdemonbag.org>
 <rVE_ZJygZO1f-s6FDZP-LJhXcAdU6IxWnYUlG5wfq3jsUltCEWAlkvg6i5PTGOZYfg6fcuhmE2VOIaMQjWPSL4EowioBOA3M544eO27CaOw=@digicana.com>
 <c621e595-6c7c-5c13-b515-44ba34d66d9a@sixdemonbag.org>
Message-ID: <NZQHh9_yBeswzCdny3YLnG-pqYb4xN0EGsHPP3BkX_6IzyG6dgUsl99I8zQsmXdQxPXMCYc44W2EqeFeOXqnwIqDmxa8LzR0zRrASi7P_4E=@digicana.com>

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 <rjh at sixdemonbag.org> 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190630/3c58cfda/attachment.html>

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: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <lrnN7VdTSkAZKTLLZOracrLNm3NegVRrVv8YrHDHcJ8zXvOooEtXlXEasLvjzgLsqFkvX5Y4DVQavGJemMwWac4ByCVgmsNL6syb0FDVO6Y=@digicana.com>
 <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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190630/2210f8b2/attachment.sig>

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: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
 <bec30f0b-c20d-5e5c-08aa-d7b6f9f888a8@riseup.net>
 <D65667D4-992A-4743-A20E-7619BBEABEA2@andrewg.com>
 <bfa9ff70-10b7-1280-2a50-25520e18be93@sixdemonbag.org>
 <fd59d544-d9b8-fc5a-1aab-f3b47082eccb@riseup.net>
 <3c41fbc2-4862-289d-d0ed-8ff3484ea98b@andrewg.com>
Message-ID: <alpine.LNX.2.21.99999.352.1906301606040.1962@Erich-PC>

-----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: <fe04bde9-cde5-add5-ca3d-c8c3f6819e78@sixdemonbag.org>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
 <bec30f0b-c20d-5e5c-08aa-d7b6f9f888a8@riseup.net>
 <D65667D4-992A-4743-A20E-7619BBEABEA2@andrewg.com>
 <bfa9ff70-10b7-1280-2a50-25520e18be93@sixdemonbag.org>
 <fd59d544-d9b8-fc5a-1aab-f3b47082eccb@riseup.net>
 <fe04bde9-cde5-add5-ca3d-c8c3f6819e78@sixdemonbag.org>
Message-ID: <bfc60a5e-6f10-f23c-a143-54932abd99f8@digitalbrains.com>

> "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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190630/eaeaf6cd/attachment-0001.sig>

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: <alpine.LNX.2.21.99999.352.1906301606040.1962@Erich-PC>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
 <bec30f0b-c20d-5e5c-08aa-d7b6f9f888a8@riseup.net>
 <D65667D4-992A-4743-A20E-7619BBEABEA2@andrewg.com>
 <bfa9ff70-10b7-1280-2a50-25520e18be93@sixdemonbag.org>
 <fd59d544-d9b8-fc5a-1aab-f3b47082eccb@riseup.net>
 <3c41fbc2-4862-289d-d0ed-8ff3484ea98b@andrewg.com>
 <alpine.LNX.2.21.99999.352.1906301606040.1962@Erich-PC>
Message-ID: <CC3BADFA-7986-40AC-ACC4-61C71C34E2E2@andrewg.com>


> On 30 Jun 2019, at 15:07, Erich Eckner via Gnupg-users <gnupg-users at gnupg.org> 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: <fd59d544-d9b8-fc5a-1aab-f3b47082eccb@riseup.net>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
 <bec30f0b-c20d-5e5c-08aa-d7b6f9f888a8@riseup.net>
 <D65667D4-992A-4743-A20E-7619BBEABEA2@andrewg.com>
 <bfa9ff70-10b7-1280-2a50-25520e18be93@sixdemonbag.org>
 <fd59d544-d9b8-fc5a-1aab-f3b47082eccb@riseup.net>
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>
 <CABGOUcxBtOaCGLKSGr88gKfgTVzqXbKX0ZVKy1zdr_-OPZyPqA@mail.gmail.com>
 <fa9b0978-9927-0456-5c09-504b5c78dcdd@bruckner.tk>
 <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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190630/f8e995e6/attachment.sig>

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: <CC3BADFA-7986-40AC-ACC4-61C71C34E2E2@andrewg.com>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
 <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org>
 <B4576B1B-54C9-46D8-922B-73CA4FCEC59A@andrewg.com>
 <bec30f0b-c20d-5e5c-08aa-d7b6f9f888a8@riseup.net>
 <D65667D4-992A-4743-A20E-7619BBEABEA2@andrewg.com>
 <bfa9ff70-10b7-1280-2a50-25520e18be93@sixdemonbag.org>
 <fd59d544-d9b8-fc5a-1aab-f3b47082eccb@riseup.net>
 <3c41fbc2-4862-289d-d0ed-8ff3484ea98b@andrewg.com>
 <alpine.LNX.2.21.99999.352.1906301606040.1962@Erich-PC>
 <CC3BADFA-7986-40AC-ACC4-61C71C34E2E2@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: <f2310bf3-65d6-bc67-077b-898ef5b077ef@gbenet.com>

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: <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
References: <gjqEvLHUNQv-g0ZSbW4J3DZcEIX9s8xu-KI2lUpNNPlXhoYg57RoFzksTNKXjfWViUvUKINoVwFreO3lCRX5shlp2PU5Gd09gGjPfui9cLQ=@digicana.com>
 <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org>
 <c443b25d-6c36-cd68-8eed-0b5276ed112a@riseup.net>
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 <rjh at sixdemonbag.org>" imported
    gpg: key F20691179038E5C6: 2 duplicate signatures removed
    gpg: key F20691179038E5C6: 2 signatures reordered
    gpg: key F20691179038E5C6: "Daniel Kahn Gillmor <dkg at fifthhorseman.net>" 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: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190630/97b93688/attachment-0001.sig>

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: <f2310bf3-65d6-bc67-077b-898ef5b077ef@gbenet.com>
References: <f2310bf3-65d6-bc67-077b-898ef5b077ef@gbenet.com>
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