sops
sops copied to clipboard
Passing age keys via stdin SOPS_AGE_KEY_FILE=/dev/stdin not working
Hi,
I want to load the age keys from a password safe (keepassxc) and pass them to sops via stdin
keepassxc-cli show -a password db.kdbx mykey | SOPS_AGE_KEY_FILE=/dev/stdin sops -d secret.yaml
but I'll get
Failed to get the data key required to decrypt the SOPS file.
Group 0: FAILED
xxx: FAILED
- | failed to create reader for decrypting sops data key with
| age: no identity matched any of the recipients
yyy: FAILED
- | failed to load age identities: failed to parse
| 'SOPS_AGE_KEY_FILE' age identities: no secret keys found
Recovery failed because the file was encrypted with a Shamir threshold of
1, but only 0 part(s) were successfully recovered, one for each successful
key group. In order for SOPS to recover the file, at least 1 groups have to
be successful. In order for a group to be successful, decryption has to
succeed with any of the keys in that key group.
Decryption works fine when I write the output from keepassxc-cli show -a password db.kdbx mykey
into a file first and use the file path in SOPS_AGE_KEY_FILE
My guess is that the code reads from SOPS_AGE_KEY_FILE
more than once. While it works during the first time, it fails during the second time, which causes failed to load age identities: ...
.
My guess is that the code reads from SOPS_AGE_KEY_FILE more than once. While it works during the first time, it fails during the second time, which causes failed to load age identities: ....
Do you mean that /dev/stdin is read twice and empty the second time when used for SOPS_AGE_KEY_FILE
?
Yes. If you look at how the error messages differ for the two keys, you can see that for the first key it apparently loaded the identities, but for the second it wasn't able to find any age identity.
I just opened #1323 for the same usecase.
Having #1323 would allow something like SOPS_AGE_KEY_EXEC="bash -c \"umask 0077; cat /dev/shm/age-key.txt || keepassxc-cli show -a password db.kdbx mykey | tee /dev/shm/age-key.txt\""
The problem here I think, is that every group is tried as an individual decryption "request", causing an isolated attempt to load credentials.
Because during the first attempt the data has already been read from stdin, any subsequent read will not be able to see this key again.