Currently, I am building a system where I fetch one or more AGE keys from a remote storage and pass them to SOPS dynamically without touching the disk or polluting environment variables. To meet strict security requirements (preventing the key from leaking via /proc//environ or persisting on disk), I am passing the keys via a file descriptor (e.g., /dev/fd/X or bash process substitution <(fetch_key)).
However, SOPS fails to process the key this way. Because file descriptors/pipes are read-once streams (non-seekable), if SOPS attempts to read the file multiple times during its execution, the stream is already exhausted after the first read, resulting in a failure.
I'd like for SOPS to support from read-once streams (like /dev/fd/* or named pipes). The ideal behavior would be for SOPS to read the contents of the key file into memory exactly once during initialization, and reuse that buffered in-memory value for all decryption operations, rather than attempting to reopen or read from the file path multiple times.
Some alternatives I've tried:
- Using SOPS_AGE_KEY: Rejected due to strict security policies. Environment variables are visible to other processes via /proc/PPID/environ and can easily leak in crash dumps or child processes.
- Writing to /tmp or /dev/shm: Rejected because writing secrets to the filesystem (even temporary or memory-backed ones) creates a risk of lingering files if the process crashes before cleanup.
I am willing to contribute and fix this! I plan to open a PR shortly to buffer the AGE key upon the first read, which should seamlessly add support for file descriptors. I'm opening this issue to track the problem and discuss the approach.
Currently, I am building a system where I fetch one or more AGE keys from a remote storage and pass them to SOPS dynamically without touching the disk or polluting environment variables. To meet strict security requirements (preventing the key from leaking via /proc//environ or persisting on disk), I am passing the keys via a file descriptor (e.g., /dev/fd/X or bash process substitution <(fetch_key)).
However, SOPS fails to process the key this way. Because file descriptors/pipes are read-once streams (non-seekable), if SOPS attempts to read the file multiple times during its execution, the stream is already exhausted after the first read, resulting in a failure.
I'd like for SOPS to support from read-once streams (like /dev/fd/* or named pipes). The ideal behavior would be for SOPS to read the contents of the key file into memory exactly once during initialization, and reuse that buffered in-memory value for all decryption operations, rather than attempting to reopen or read from the file path multiple times.
Some alternatives I've tried:
I am willing to contribute and fix this! I plan to open a PR shortly to buffer the AGE key upon the first read, which should seamlessly add support for file descriptors. I'm opening this issue to track the problem and discuss the approach.