Feature #11905
Consider dropping custom keyserver settings on Stretch
100%
Description
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.
Subtasks
Related issues
Related to Tails - |
Resolved | 2016-11-17 |
History
#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 127.0.0.1
? I wonder what dirmngr functionality we lose by using the Tor DNS resolver, instead of the more capable 8.8.8.8; 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 ingpg(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 usehkp://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.