--encrypt-key: accept GPG user id formats (eg. email address) other than hex key ID

I have:

  • ([x] when completed)
  • searched https://gitlab.com/duplicity/duplicity/-/issues for similar issues. If you find a similar issue and the issue is still open, add a comment to the existing issue instead of opening a new one. If you find a Closed issue that seems like it is the same thing that you're experiencing, open a new issue and include a link to the original issue in the body of your new one.
  • tested that this issue still occurs on the latest stable snap (install instructions: https://snapcraft.io/duplicity), please include the snap version (snap info duplicity | grep installed) output: installed: 3.0.5.dev5 (566) 130MB classic
  • ideally, tested that this issue still occurs on the latest edge snap, if you can test without risking your data. Please include the snap version output: installed: 3.0.5.dev5 (566) 130MB classic

Summary

--encrypt-key: accept GPG user id formats (eg. email address) other than hex key ID

Environment

Debian 12

duplicity 3.0.5.dev5 March 24, 2025

duplicity --encrypt-key user@example.com full ~/Pictures/ file:///tmp/backups/

Steps to reproduce

  1. Generate a key using an e-mail address: gpg --gen-key Email address: user@example.com
  2. Run duplicity with encryption for that key: duplicity --encrypt-key user@example.com full ~/Pictures/ file:///tmp/backups/ CommandLineError: Encrypt key should be an 8, 16, or 40 character hex string, like 'AA0E73D2'. Received 'user@example.com' length=16 instead. Enter 'duplicity --help' for help screen.

What is the current bug behaviour?

CommandLineError: Encrypt key should be an 8, 16, or 40 character hex string, like 'AA0E73D2'. Received 'user@example.com' length=16 instead.

What is the expected correct behaviour?

duplicity performs a full backup and encrypts for that key

Relevant logs and/or screenshots

$ gpg -k gpg: checking the trustdb gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 3 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 3u gpg: next trustdb check due at 2027-03-26 ... pub rsa3072 2025-03-26 [SC] [expires: 2027-03-26] DB925AB74F76318D48D6FE2F2A61FBCA7ACBEC64 uid [ultimate] user@example.com sub rsa3072 2025-03-26 [E] [expires: 2027-03-26]

Confirming gpg can accept such user ID styles:

$ echo foo | gpg -e --armor -r user@example.com - -----BEGIN PGP MESSAGE-----

hQGMA0WSPNoP1db0AQv/dzRolbxxVwaOxu6eYCVWgppbug1bzRgl6sVtuadRFwF8 7u7CrPSDI5URT/NpbS1vLK7hEx6zWE5uB+n7Pss/rb9ke9KNPgf6il+BNS9uy9GE r8cvZp1A63vB/uI3j46AFby7Wyicfj3qFayYWUHm7uoDeoZnLaS5AtLz50RZlMUl LDPWx+MDzYtiJyXZrNEEnztqX6Nr8hE2UxOH0x7dJNPnGU+4Nxx0avmHxyLdsu0H N+Pc69/W9aoQjl2RTebyRyiTlVw2BqWtpao422AnpA3BIqUr+85IqcLRBBz852l8 ZZk3LVedM5boYT6289SLpp67NYgsqw52EXRJAQQe4kr2D2sfpL4J9qWoJVTurpy1 ruB06qLtlMBPR1ykn+CldAEjf+CPwmUQuoDK8mC0htMJUpXAGQ+qi+19hCJrb5kq l72tbfmnQ0Omgwezq2sKlFIynH+vX2xWYyOK4Cq3PYBhOVL61ctI+QvTBo2oSSge Clro3p89NMVt0zEDRfu10j8BSOcyI5a37q1oNhI2od38TZtCGAteLNAmGGkhtHv9 s5WBl7kbK5JffP4rd/tfdNz6dVPwFhbEBDqyuYlwoNA= =BRF4 -----END PGP MESSAGE-----

GnuPG reference for all accepted User ID styles:

https://www.gnupg.org/documentation/manuals/gnupg24/gpg.1.html#:~:text=HOW%20TO%20SPECIFY%20A%20USER%20ID

Here's a bit of archaeology in duplicity around validation of GnuPG key ID command-line flags.

  1. 2002 - initial checkin - only sign-key is validated (https://gitlab.com/duplicity/duplicity/-/blob/9d03b092b6fad300a121a7bb7746ef718ddc424c/duplicity/commandline.py#L58 encrypt-key is not validated
  2. 2023 - port to argparse (Python 3) - now also encrypt-key starts being validated https://gitlab.com/duplicity/duplicity/-/blob/47fbd14f6665859ecab32ca3447cf6151c7fcedb/duplicity/cli_util.py#L285

Possible fixes

  1. Update gpg_key_patt to accept other GnuPG user ID types (reference: https://www.gnupg.org/documentation/manuals/gnupg24/gpg.1.html#:~:text=HOW%20TO%20SPECIFY%20A%20USER%20ID) This might make the check quite permissive.
  2. Update set_encrypt_key etc to call GnuPG for validation. Might be heavyweight but very 'correct'
  3. Stop validating entirely. GnuPG will eventually validate the user ID when called. If a user provides incorrect user ID, this delays the time until they are warned there is a problem.

Formatting

PLEASE DO NOT copy/paste long listings to the issue. Use the attach file option to attach a file instead. This makes it much easier to read and to process by the developers.

Edited by Catalin Patulea