Package: gnupg Version: 2.2.17-3 Severity: important Hello!
After upgrading gnupg to version 2.2.17-3, I noticed that its NEWS.Debian.gz file announces a default behavior change: | Upstream GnuPG now defaults to not accepting third-party certifications | from the keyserver network. Given that the SKS keyserver network is | under attack via certificate flooding, and third-party certifications | will not be accepted anyway, we now ship with the more tightly-constrained | and abuse-resistant system hkps://keys.openpgp.org as the default | keyserver. | [...] Hence, if I understand correctly, gpg now only pulls self-signatures from keyservers (unless explicitly configured to do otherwise). Moreover, Debian packaged gpg now uses an isolated keyserver, by default. I am aware of the certificate flooding attack that's currently going on, since I read some blog articles about it and took a look at some [bug] [reports]. As a consequence, I really appreciate all the attempts to mitigate and/or solve the issue, as I myself suffered from significant slow downs, while refreshing keys in my pubring. [bug]: <https://bugs.debian.org/931339> [reports]: <https://dev.gnupg.org/T4592> However, I am a bit puzzled by this specific strategy to mitigate the issue. I mean: it's not clear to me how the web of trust is going to work, from now on. Only pulling self-signatures from keyservers means I will no longer benefit from indirect trust paths (I signed Bob's key, Bob signed Alice's key, hence I can indirectly trust Alice's key, although I have not yet met Alice personally). Right? I can only trust keys of people I had the opportunity to meet personally. Or am I completely off track? Moreover, the usual recommendation after an identity and key fingerprint verification (at a key signing party or otherwise), is to sign Bob's key and then send the signed key to the Bob's e-mail address, in an encrypted message: Bob will send the signature to the keyserver network, only if he is in control of the secret key and if he actually wants the new signature to be disclosed to the public. This is the default procedure implemented in caff, isn't it? Following this procedure, I do not import my own signature on Bob's key until Bob decides he wants to publish my signature on the keyserver network. But, if gpg only imports self-signatures from the keyservers, I will not even get my own signature on Bob's key, unless I manually import it into my pubring. Am I misunderstanding the whole thing? Please clarify and/or document these consequences in the gnupg Debian package, so that users have an opportunity to be informed and adapt their habits and expectations... Thanks a lot for your time and dedication! Bye. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnupg depends on: ii dirmngr 2.2.17-3 ii gnupg-l10n 2.2.17-3 ii gnupg-utils 2.2.17-3 ii gpg 2.2.17-3 ii gpg-agent 2.2.17-3 ii gpg-wks-client 2.2.17-3 ii gpg-wks-server 2.2.17-3 ii gpgsm 2.2.17-3 ii gpgv 2.2.17-3 gnupg recommends no packages. Versions of packages gnupg suggests: pn parcimonie <none> pn xloadimage <none> -- no debconf information
