Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unable to force specific gpg subkey #1365

Open
mammothbane opened this issue Dec 5, 2023 · 2 comments · May be fixed by #1522
Open

unable to force specific gpg subkey #1365

mammothbane opened this issue Dec 5, 2023 · 2 comments · May be fixed by #1522

Comments

@mammothbane
Copy link

situation

I use sops to manage secrets for my projects, all using GPG for encryption.

I have a GPG master key with several encryption subkeys:

  • One on my YubiKey (oldest)
  • One on my desktop at home
  • One on my desktop at work (newest)

I just recently added the desktop and work subkeys, and am hoping to be able to configure sops to encrypt my secrets with all of these subkeys so that I can recover in the eventuality that I lose the YubiKey.

state of the world

As far as I understand:

  • sops shells out to gpg to encrypt/decrypt
  • When given a master key fingerprint to use for encryption, gpg will always use the newest encryption subkey
  • By default, any subkey fingerprint passed to gpg will cause it to lookup the master key first, then select an encryption subkey (which will always be the newest one per above)
  • It is possible to override this behavior by passing a specific subkey fingerprint followed by an exclamation mark (disables master key lookup and forces the use of the specified fingerprint)
  • sops truncates key fingerprints to 16 characters during encryption for compatibility reasons

As a result, it isn't possible to tell sops to use a specific key fingerprint, since for a keyid like 0123456789ABCDEF!, sops will produce 123456789ABCDEF! , which is rejected by gpg as malformed.

In my case, this means that everything sops encrypts that points at my gpg key can be encrypted only with my work encryption key, as it's the newest.

proof of concept

The following patch solves this problem for me and lets me specify an exclamation-mark fingerprint to sops:

diff --git a/pgp/keysource.go b/pgp/keysource.go
--- pgp/keysource.go
+++ pgp/keysource.go
@@ -625,9 +625,6 @@
 // shortenFingerprint returns the short ID of the given fingerprint.
 // This is mostly used for compatibility reasons, as older versions of GnuPG
 // do not always like long IDs.
 func shortenFingerprint(fingerprint string) string {
-	if offset := len(fingerprint) - 16; offset > 0 {
-		fingerprint = fingerprint[offset:]
-	}
 	return fingerprint
 }

proposed upstream

In shortenFingerprint, special-case strings with terminal !, chopping the string to 17 characters rather than 16, retaining the full key and the !. If amenable, I could PR this.

related

#808

@jflanglois
Copy link

jflanglois commented Dec 15, 2023

I ran into this specific issue yesterday! I have multiple subkeys for different devices so need a way to specify them. It seems to me like the behavior should be to try the long key first and fall back to shortening (or even just have users in those environments manually specify short ids). @hiddeco do you have more detail on which versions of gpg would barf on long fingerprints?

@Luflosi
Copy link

Luflosi commented Mar 10, 2024

I also ran into this problem.
I'm working around it with the above patch. Thanks @mammothbane!

tilpner added a commit to tilpner/sops that referenced this issue Jun 6, 2024
If shortening fingerprints, the trailing '!' from subkey fingerprints is removed,
and the wrong key is selected later on, potentially resulting in just-created secrets
not being decryptable.

Fixes getsops#1365
@tilpner tilpner linked a pull request Jun 6, 2024 that will close this issue
tilpner added a commit to tilpner/sops that referenced this issue Jun 6, 2024
If shortening fingerprints, the trailing '!' from subkey fingerprints is removed,
and the wrong key is selected later on, potentially resulting in just-created secrets
not being decryptable.

Fixes getsops#1365

Signed-off-by: tilpner <[email protected]>
tilpner added a commit to tilpner/sops that referenced this issue Jun 6, 2024
If shortening fingerprints, the trailing '!' from subkey fingerprints is removed,
and the wrong key is selected later on, potentially resulting in just-created secrets
not being decryptable.

Fixes getsops#1365

Signed-off-by: tilpner <[email protected]>
tilpner added a commit to tilpner/sops that referenced this issue Jun 14, 2024
If shortening fingerprints, the trailing '!' from subkey fingerprints is removed,
and the wrong key is selected later on, potentially resulting in just-created secrets
not being decryptable.

Fixes getsops#1365

Signed-off-by: tilpner <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants