You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Which results in an output like this (showing only the relevant lines):
gpg: encrypted with 256-bit ECDH key, ID ...
gpg: public key decryption failed: General error
gpg: decryption failed: No secret key
...
gpg: encrypted with 256-bit ECDH key, ID ...
gpg: public key decryption failed: General error
gpg: decryption failed: No secret key
...
gpg: encrypted with 256-bit ECDH key, ID ...
bar
...
As you can see, only one of the three GPG processes successfully decrypts the input, while the other two fail with a "General error". Not sure if it matters, but I'm using a "touch policy: always" decrypting key as a subkey on a master key (setup as shown here), and specifying the master key id for the KEYID.
I discovered this issue when using a Terraform sops provider and defining several sops_file data blocks. Plans with that fail as GPG tries to decrypt several files at a time and runs into this issue, so it impacts real world use. I did find a workaround for that specific issue, as sops lets you define a custom path for the GPG executable. So I wrote a script that would lock the GPG process using flock and pointed SOPS_GPG_EXEC to it:
#!/bin/bash# Process locking workaround for sops compatibility with piv-agent.# Point SOPS_GPG_EXEC environmental variable to this script.
(
# Fail after a minute of waiting.
flock -x -w 60 200 ||exit 60
gpg "$@"
) 200>/tmp/piv-agent-gpg-lock
The text was updated successfully, but these errors were encountered:
This issue can be reproduced using the following script (export KEYID variable before running):
Which results in an output like this (showing only the relevant lines):
As you can see, only one of the three GPG processes successfully decrypts the input, while the other two fail with a "General error". Not sure if it matters, but I'm using a "touch policy: always" decrypting key as a subkey on a master key (setup as shown here), and specifying the master key id for the KEYID.
I discovered this issue when using a Terraform sops provider and defining several
sops_file
data blocks. Plans with that fail as GPG tries to decrypt several files at a time and runs into this issue, so it impacts real world use. I did find a workaround for that specific issue, as sops lets you define a custom path for the GPG executable. So I wrote a script that would lock the GPG process usingflock
and pointedSOPS_GPG_EXEC
to it:The text was updated successfully, but these errors were encountered: