Feature #11905

Consider dropping custom keyserver settings on Stretch

Added by intrigeri 2016-11-11 09:08:32 . Updated 2016-12-22 19:16:24 .

Target version:
Start date:
Due date:
% Done:


Feature Branch:
Type of work:

Affected tool:
Deliverable for:


Since gnupg2 (2.1.15-9), “If no keyserver is explicitly configured, dirmngr will use the built-in default of hkps://hkps.pool.sks-keyservers.net” (dirmngr(8)). So perhaps we can drop our custom settings.


Related issues

Related to Tails - Bug #11948: Enigmail fails to talk to keyservers on Stretch Resolved 2016-11-17


#1 Updated by intrigeri 2016-11-15 11:26:22

That gnupg2 version should migrate to testing today or tomorrow. Likely we’ll have bumped the APT snapshots we use already, so this will be for the next round (late December).

#2 Updated by bertagaz 2016-11-16 15:25:47

  • Status changed from Confirmed to In Progress
  • Assignee changed from intrigeri to bertagaz
  • Feature Branch set to bugfix/11905-gnupg2-default-keyserver

#3 Updated by intrigeri 2016-11-17 15:36:36

Here’s an initial code review at commit:819ec483e066ecf1e99c6e7b71b84e61eac3845c.

  • wiki/src/contribute/design.mdwn needs updating:
    • config/chroot_local-includes/etc/skel/.gnupg/dirmngr.conf should be mentioned in there
    • the part about config/chroot_local-includes/etc/ssl/certs/sks-keyservers.netCA.pem should be adjusted
    • I’ll let you check the GnuPG section and see what else needs to be done, if anything.
  • Why do we do nameserver I wonder what dirmngr functionality we lose by using the Tor DNS resolver, instead of the more capable; e.g. there may be useful info that can only be found using SRV records.
  • keyserver-options include-revoked is left is place (which seems correct), but the corresponding comment was removed. Mistake?
  • Why was keyserver-options no-honor-keyserver-url removed? I still see it documented in gpg(1), which makes sense since it seems to affect the way GnuPG will call dirmngr.

#4 Updated by bertagaz 2016-11-17 15:59:01

  • Assignee changed from bertagaz to intrigeri
  • % Done changed from 0 to 60
  • QA Check set to Ready for QA

I think I’ve fixed all your comments and the CA certificate bug as explained. Last commits are pushed and this branch is now RfQA (finally…).

#5 Updated by bertagaz 2016-11-17 16:12:57

bertagaz wrote:
> I think I’ve fixed all your comments and the CA certificate bug as explained. Last commits are pushed and this branch is now RfQA (finally…).

So I tested to fetch keys with:

  • Seahorse started from GNOME menu: works
  • Seahorse started from the GPGApplet: works
  • Enigmail: fails. Talk about ‘configuration error’ when trying to refresh the public keyring, otherwise complains it can’t find the key when trying to fetch one from the keyservers.

#6 Updated by intrigeri 2016-11-17 16:28:05

  • % Done changed from 60 to 10
  • QA Check deleted (Ready for QA)
  • Feature Branch deleted (bugfix/11905-gnupg2-default-keyserver)

Now that the somewhat related bugfix/11905-gnupg2-default-keyserver was merged, let’s get back to using this ticket for its initial purpose. Thanks to that branch, we now have the right GnuPG v2 version. But at least Enigmail still has the keyserver hard-coded.

#7 Updated by bertagaz 2016-11-17 16:28:49

  • related to Bug #11948: Enigmail fails to talk to keyservers on Stretch added

#8 Updated by intrigeri 2016-12-22 19:16:24

  • Status changed from In Progress to Resolved
  • % Done changed from 10 to 100
  • When extensions.torbirdy.custom.extensions.enigmail.keyserver is not set, Torbirdy configures Enigmail to use hkp://qdigse2yzvuglcix.onion. So we can’t easily drop this one.
  • Next (and last) one is GNOME’s (config/chroot_local-includes/etc/dconf/db/local.d/00_Tails_defaults): last time I checked, Seahorse had its own code to communicate with keyservers, so we can’t rely on it using GnuPG’s sane defaults. Let’s give it up for now.