Home-manager users can help test gnupg-2.3.1 (beta)!

1

Hi. I know some others in the NixOS community are (begrudging) gpg users.

There are a number of features in the beta 2.3 release, headed for the stable 2.4 series, that I am interested in testing. (See below for the list) But in particular:

  • A new experimental key database daemon is provided. To enable it
    put “use-keyboxd” into gpg.conf and gpgsm.conf. Keys are stored
    in a SQLite database and make key lookup much faster.

  • New tool gpg-card as a flexible frontend for all types of
    supported smartcards.

  • tpm2d: New daemon to physically bind keys to the local machine.
    See 20210315-using-tpm-with-gnupg-2.3

  • scd: Support PIV cards.

  • scd: New option --pcsc-shared; see man page for important notes.

So, I threw together:

  1. a PR to home-manager that makes the programs.gpg/services.gpg-agent package configurable: gnupg/gpg-agent: gnupg package is configurable by colemickens · Pull Request #1949 · nix-community/home-manager · GitHub
  2. a nixpkgs commit to add the gpg-2.3.1 package: https://github.com/colemickens/nixpkgs/commit/3989c71f5cb0eca2764f9025dfe848f7143d2103

Just throwing it out there in case others want to test PIV card support, or maybe reproducible gpg keys provisionable with gpg-card… :slight_smile: . (and/or in case you want to +1 the home-manager pull request!)

Full list of notable 2.3 features:

  • A new experimental key database daemon is provided. To enable it
    put “use-keyboxd” into gpg.conf and gpgsm.conf. Keys are stored
    in a SQLite database and make key lookup much faster.

  • New tool gpg-card as a flexible frontend for all types of
    supported smartcards.

  • New option --chuid for gpg, gpgsm, gpgconf, gpg-card, and
    gpg-connect-agent.

  • The gpg-wks-client tool is now installed under bin; a wrapper for
    its old location at libexec is also installed.

  • tpm2d: New daemon to physically bind keys to the local machine.
    See 20210315-using-tpm-with-gnupg-2.3

  • gpg: Switch to ed25519/cv25519 as default public key algorithms.

  • gpg: Verification results now depend on the --sender option and
    the signer’s UID subpacket. [#4735]

  • gpg: Do not use any 64-bit block size cipher algorithm for
    encryption. Use AES as last resort cipher preference instead of
    3DES. This can be reverted using --allow-old-cipher-algos.

  • gpg: Support AEAD encryption mode using OCB or EAX.

  • gpg: Support v5 keys and signatures.

  • gpg: Support curve X448 (ed448, cv448).

  • gpg: Allow use of group names in key listings. [e825aea2ba]

  • gpg: New option --full-timestrings to print date and time.

  • gpg: New option --force-sign-key. [#4584]

  • gpg: New option --no-auto-trust-new-key.

  • gpg: The legacy key discovery method PKA is no longer supported.
    The command --print-pka-records and the PKA related import and
    export options have been removed.

  • gpg: Support export of Ed448 Secure Shell keys.

  • gpgsm: Add basic ECC support.

  • gpgsm: Support creation of EdDSA certificates. [#4888]

  • agent: Allow the use of “Label:” in a key file to customize the
    pinentry prompt. [5388537806]

  • agent: Support ssh-agent extensions for environment variables.
    With a patched version of OpenSSH this avoids the need for the
    “updatestartuptty” kludge. [224e26cf7b]

  • scd: Improve support for multiple card readers and tokens.

  • scd: Support PIV cards.

  • scd: Support for Rohde&Schwarz Cybersecurity cards.

  • scd: Support Telesec Signature Cards v2.0

  • scd: Support multiple application on certain smartcard.

  • scd: New option --application-priority.

  • scd: New option --pcsc-shared; see man page for important notes.

  • dirmngr: Support a gpgNtds parameter in LDAP keyserver URLs.

  • The symcryptrun tool, a wrapper for the now obsolete external
    Chiasmus tool, has been removed.

  • Full Unicode support under Windows for the command line. [#4398]

Release-info: ⚓ T5343 Release GnuPG 2.3.0

GnuPG 2.3 annonce email: [Announce] GnuPG 2.3.0 released

6 Likes
2

(Maybe it’s obvious, but this is slightly novel in that it doesn’t require rebuilding everything in your system, such as if you used an overlay to provide the updated gpg.)

3

Just a heads up, so far things are not looking so great. I can’t use my yubikey for things and a Mac user in IRC reported the same exact upgrade/breakage. Maybe hold off, especially if you only have a yubikey…

1 Like
4

Please ping me when you think your changes have stabilized and I will test.

5

related: ⚓ T5409 scdaemon: 'Operation not supported by device' error under macOS after upgrading to 2.3.1

Hmm… do we not have https://www.gnupg.org/howtos/card-howto/en/gnupg-ccid.rules in a nixos module somewhere?

Tracking issue for NixOS for CCID udev rules: gnupg-ccid.rules - rules for CCID permission configuration · Issue #120694 · NixOS/nixpkgs · GitHub

I’m not sure if that will fix this, but the gnupg issue I linked has another workaround that I could implement via home-manager…

1 Like
6

Oh wow. Yubikey users are going to have a blast upgrading to 2.3.

https://dev.gnupg.org/T4673

Looks like this is intentional for users that were using PC/SC and didn’t have disable-ccid set.

7

There’s a lot going on, all touching pieces of an extremely fragile, annoying ecosystem (I don’t think anyone really disagrees about the state of the gnupg world).

… But I do have gnupg-2.3 working with scdaemon, ccid, and no pcscd. Which isn’t necessarily what I was aiming for, but at least I can be unblocked without havinng to downgrade to gnupg-2.2.

I will send nixpkgs PRs for the gnupg-ccid-udev-rules and for gnupg-23, just in the interest of facilitating testing. And then update this PR with instructions for further testing if you don’t want to follow the crumbs I’ve left so far.

8

Two more PRs to help testing:

The first one is going to require a bit more investigation from me.

The second just needs a review and merge, so I don’t have to keep pointing people to a moving commit on my nixpkgs.

Another update: all of the issues I’ve hit may be unrelated to gnupg-2.3 and instead be related to: pcscd: fails to start · Issue #121088 · NixOS/nixpkgs · GitHub still investigating…

9

121088 will be fixed in a few minutes.

1 Like
10

Assuming it evals, I’ll merge the fix shortly.

1 Like
11

Do you need testing on Fedora+home-manager? If yes, please tell me what I should test.

12

Summary:

  1. It seems like all of the “issues” that I’ve been worried about are mostly related to pcscd. One issue is fixed on master; the current outstanding issue is here: pcscd's nixos module by default returns policykit auth errors · Issue #121121 · NixOS/nixpkgs · GitHub.

    but, this issue also affects current gpg users that use pc/sc->pcscd! it’s not related to the gpg update.

  2. If you choose to not use pcscd, then you must provide something that enables udev rules that enable scdaemon to access the smartcard via CCID. This can be done with one of these options:

    # option 1: requires this PR: https://github.com/NixOS/nixpkgs/pull/121085
# uses scdaemon.udev rules from debian
hardware.gpgSmartcards.enable = true;

# or
# this pull yubikey's udev rules into the environment
services.udev.packages = [ pkgs.yubikey-personalization ];

  3. I have written this horribly over-engineered Nix expression that allows me to test 4 distinct GPG scenarios: https://github.com/colemickens/nixcfg/blob/3e0fa46934f7a8a9b1daabfc975728cf4ea22a87/mixins/gpg-agent.nix. I think they should all work, now that I’ve incorporated the workaround mentioned in #121121.

This over-engineered monstrosity allows me to test out:

  • no-pcscd + gpg-2.3 + gpg scdaemon udev rules
  • no-pcscd + gpg-2.3 + yubikey udev rules
  • pcscd + no udev rules + gpg-2.3 with “disable-ccid” so it forces pc/sc usage
  • pcscd + no udev rules + gpg-2.2 with no “disable-ccid”, so it fallbacks to pc/sc

And it automatically ensures that scdaemon/gpg-agent are rebooted automatically on each toplevel activation to ensure I’m actually testing the right thing. Kinda neat, kinda horrifying.

That’s been my testing methodology anyway, I’m not sure what would be appropriate to consider with Fedora+HM.

1 Like