Project

General

Profile

Feature #11905

Consider dropping custom keyserver settings on Stretch

Added by intrigeri about 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
11/11/2016
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

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.


Related issues

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

Associated revisions

Revision a2258fd7 (diff)
Added by bertagaz about 3 years ago

Grant freeze exception for gnupg2.

Will-fix: #11905

Revision 345176e5 (diff)
Added by bertagaz about 3 years ago

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.

Will-fix: #11905

Revision 88f9d972 (diff)
Added by bertagaz about 3 years ago

Properly configure dirmngr.

Will-fix: #11905

Revision d5b60d38 (diff)
Added by bertagaz about 3 years ago

Fix GnuPG2 APT pining.

Some binary packages were missing.

Will-fix: #11905

Revision 819ec483 (diff)
Added by bertagaz about 3 years ago

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.

Will-fix: #11905

Revision a8b7dc98 (diff)
Added by bertagaz about 3 years ago

Remove useless nameserver option to dirmngr.conf

Will-fix: #11905

Revision 5990a97c (diff)
Added by bertagaz about 3 years ago

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
shouldn't do.

Will-fix: #11905

Revision 73eaceea (diff)
Added by bertagaz about 3 years ago

Add back gpg.conf option comment.

Will-fix: #11905

Revision a88ea18f (diff)
Added by bertagaz about 3 years ago

Update design doc for GnuPG2.

Will-fix: #11905

Revision a718a8f2
Added by intrigeri about 3 years ago

Merge remote-tracking branch 'origin/bugfix/11905-gnupg2-default-keyserver' into feature/stretch

refs: #11905

History

#1 Updated by intrigeri about 3 years ago

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 about 3 years ago

  • 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 about 3 years ago

Here's an initial code review at 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 in gpg(1), which makes sense since it seems to affect the way GnuPG will call dirmngr.

#4 Updated by bertagaz about 3 years ago

  • 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 about 3 years ago

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 about 3 years ago

  • % 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 about 3 years ago

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

#8 Updated by intrigeri almost 3 years ago

  • 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.

Also available in: Atom PDF