Issue while decrypting secrets with sops 3.2 and gpg 2.2

[SahilMj]

I have my mac running on below sops and gpg versions (3.2.0 and 2.2.13) respectively.

$ sops --version
sops 3.2.0
[warning] failed to retrieve latest version from upstream: Version information not found in upstream file

[warning] failed to compare current version with latest: Version string empty
 (latest)
$ gpg --version
gpg (GnuPG) 2.2.13
libgcrypt 1.8.4
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /Users/sahilmahajan/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

But I am facing issues while decrypting secrets,

Failed to get the data key required to decrypt the SOPS file.
 508405C0A353AA2A: FAILED
    - | could not decrypt data key with PGP key:
      | golang.org/x/crypto/openpgp error: Reading PGP message
      | failed: openpgp: incorrect key; GPG binary error: exit
      | status 2

Recovery failed because no master key was able to decrypt the file. In
order for SOPS to recover the file, at least one key has to be successful,
but none were.
Error: plugin "secrets" exited with error

I tried with this resolution and appended the below 2 lines in ".bash_profile".

GPG_TTY=$(tty)
export GPG_TTY

But the issue is still there. Could this be an issue with sops version ?

[mwasilew2]

In my case the problem was caused by trying to use a subkey and having multiple public subkeys in my keyring (I had a primary key and two subkeys with encryption capabilities, both were not revoked).

Sops is actually using the GnuPG binary on the system (rather than using a library that would implement OpenPGP for example). In .sops.yaml I provided a long fingerprint of one of my subkeys with encryption capability. I expected it to be used, but what I was not aware was that GnuPG doesn't work this way. What happened was GnuPG binary took the subkey key ID and resolved it to the primary key ID. It then tried to look up a key with an encryption capability under the primary key. The selection algorithm points to the newest matching subkey which in this case was a different subkey than the one that I wanted to use (both were created on the same day, it's not like one replaced the other, but yes there was a time difference). The result was that the file was encrypted using a different key than the one specified in .sops.yaml

So everything was fine with sops and GnuPG, the solution was simply to use a different key (and learn about GnuPG 😄 )

What helped me with debugging was logs from gpg-agent, verbose output from gpg2, decrypting the PGP message from the encrypted secrets.yaml file (the fp field was pointing to a different key than the message was actually encrypted with which took me a while to figure out)

Other potentially related issues:

• Support for gpg2? #189
• Cannot decrypt with GPG 2.2.5 and SOPS 3.0.0 #304
• how to use with Yubikey zendesk/helm-secrets#113