Consider dropping custom keyserver settings on Stretch
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.
Remove the CA certificate we ship for sks-keyservers.net
It's shipped in Debian GnuPG2 package now. It's not imported in the
system CAs though, so we need to link it in the proper directory so that
it's installed with `update-ca-certificates` and we don't need to change
GnuPG2 dirmngr configuration to point to this certificate.
Create the directory required by 58-create-tails-website-CA-bundle hook.
The `/usr/local/etc/ssl/certs/` directory was previously created as we
included the sks-keyservers certificate in chroot_local-includes. Now
that this certificate has disappeared from our source tree, we need to
create this directory in this hook.
Point dirmngr to the sks-keyservers.net CA certificate shipped by GnuPG.
This way we don't trust it system-wise for other operation that
#3 Updated by intrigeri about 3 years ago
Here's an initial code review at 819ec483e066ecf1e99c6e7b71b84e61eac3845c.
config/chroot_local-includes/etc/skel/.gnupg/dirmngr.confshould be mentioned in there
- the part about
config/chroot_local-includes/etc/ssl/certs/sks-keyservers.netCA.pemshould 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 18.104.22.168; e.g. there may be useful info that can only be found using SRV records.
keyserver-options include-revokedis left is place (which seems correct), but the corresponding comment was removed. Mistake?
- Why was
keyserver-options no-honor-keyserver-urlremoved? I still see it documented in
gpg(1), which makes sense since it seems to affect the way GnuPG will call dirmngr.
#5 Updated by bertagaz about 3 years ago
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 about 3 years ago
- % Done changed from 60 to 10
- QA Check deleted (
Ready for QA)
- Feature Branch deleted (
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.
#8 Updated by intrigeri about 3 years ago
- Status changed from In Progress to Resolved
- % Done changed from 10 to 100
extensions.torbirdy.custom.extensions.enigmail.keyserveris 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.