sops hangs until gpg agent restarted (mac)

[t3h2mas]

what: sops decrypts a file once, on further decryption attempts, sops hangs until gpg agent is restarted.

setup:

• exported SOPS_PGP_FP
• created the file "newtest.json" with sops newtest.json
• ran sops -d newtest.json
• the decrypted output appears
• ran sops -d newtest.json again, it hangs indefinitely without ouput
• ctrl+c sops to stop it
• kill gpg-agent with gpgconf --kill gpg-agent
• sops -d newtest.json works again
• repeats hanging on decryption

is there a better way to debug this?

versions:
macOS 10.13.3
sops 3.0.3 (latest)
gpg (GnuPG/MacGPG2) 2.2.3

[autrilla]

Have you checked this a problem with SOPS, and not a problem with your gpg-agent setup? I can't reproduce this on my machine with macOS 10.13.4, sops 3.0.3 and gpg 2.2.6

[t3h2mas]

@autrilla Do you have any relevant configuration you could share for your agent setup? I am using the vanilla configuration. (installed via gpg suite)

[autrilla]

I don't have any configuration tweaks. I install gpg and gpg-agent through Homebrew on macOS

[ekristen]

I see this behavior too, I have to literally kill the gpg-agent each time I want to decrypt.

[uwehdaub]

I see the same behavior with sops 3.5.0 under Ubuntu 18.04.
And after some debugging I truly believe, it's related to a know bug in the x/crypto/opengpg package from golang:
golang/go#28786

I compiled a version of sops with more logging and this shows the endless loop (indirectly by calling the callback passphrasePrompt:

>> sops -d ~/work/sops/secrets 
[PGP]	 INFO[0000] entering function decryptWithCryptoOpenpgp   
[PGP]	 INFO[0000] entering function loadRing with path  /home/uwe/.gnupg/secring.gpg 
[PGP]	 INFO[0000] leaving  function loadRing                   
[PGP]	 INFO[0000] decryptWithCryptoOpenpgp: got keyring        
[PGP]	 INFO[0000] decryptWithCryptoOpenpgp: armor decoded      
[PGP]	 INFO[0000] calling function openpgp.ReadMessage         
[PGP]	 INFO[0000] entering function passphrasePrompt           
[PGP]	 INFO[0000] key candidates [{Entity:0xc000360050 PublicKey:0xc000342680 PrivateKey:0xc000342680 SelfSignature:0xc0000faa80}] 
[PGP]	 INFO[0000] is key symmetric: false                      
[PGP]	 INFO[0000] return with pass with len 18                 
[PGP]	 INFO[0000] leaving  function passphrasePrompt           
[PGP]	 INFO[0000] entering function passphrasePrompt           
[PGP]	 INFO[0000] key candidates [{Entity:0xc000360050 PublicKey:0xc000342680 PrivateKey:0xc000342680 SelfSignature:0xc0000faa80}] 
[PGP]	 INFO[0000] is key symmetric: false                      
[PGP]	 INFO[0000] return with pass with len 18                 
[PGP]	 INFO[0000] leaving  function passphrasePrompt           
[PGP]	 INFO[0000] entering function passphrasePrompt           
[PGP]	 INFO[0000] key candidates [{Entity:0xc000360050 PublicKey:0xc000342680 PrivateKey:0xc000342680 SelfSignature:0xc0000faa80}] 
[PGP]	 INFO[0000] is key symmetric: false                      
[PGP]	 INFO[0000] return with pass with len 18                 
[PGP]	 INFO[0000] leaving  function passphrasePrompt           
[PGP]	 INFO[0000] entering function passphrasePrompt           
[PGP]	 INFO[0000] key candidates [{Entity:0xc000360050 PublicKey:0xc000342680 PrivateKey:0xc000342680 SelfSignature:0xc0000faa80}] 
[PGP]	 INFO[0000] is key symmetric: false                      
[PGP]	 INFO[0000] return with pass with len 18                 
[PGP]	 INFO[0000] leaving  function passphrasePrompt

[ekristen]

I can confirm linux see this behavior as well. This even happens when there are no suitable PGP keys available. IE using key groups and a KMS and GPG keys