Feature-parity with `age`: identity files via `-` about rage HOT 7 CLOSED

Named pipes have the same limitation as stdin: The function read_recipients assumes the identity path is a file that can be read multiple times. age reads the "file" once so it works with pipes and stdin. Update: perhaps this isn't a multi-read issue, it might be due to stdin or pipe not being closed. If that's the problem, then a fix may be either for the caller to close the input stream or pipe (preferable), or the reader (rage) to use nonblocking io.

age-keygen -o my-secret
echo hello | age -e -i my-secret > hello.age

# age
mkfifo fifo-1 && cat my-secret > fifo-1 &
cat hello.age | age -d -i fifo-1
# outputs "hello" as expected (and background task exits)

# rage
mkfifo fifo-2 && cat my-secret > fifo-2 &
cat hello.age | rage -d -i fifo-2 
# hangs (and background task exits)

Why pipes?
One advantage of pipes over stdin is that the pipe can be used in streaming use cases where stdin is the file being encrypted or decrypted. Like files, pipes appear in the file system, which creates a potential exposure where other processes might be able to read the secret, but it's arguably lower risk than files because it can be read only once.

I'd prefer to use an environment variable containing the identity key, rather than a pipe, but in the interests of maintaining compatibility with age, that would require changing the spec and both implementations. What do others think?

from rage.

@str4d Are you open to a PR that accepts environment variables with the prefix "OP_IDENTITY" (examples: OP_IDENTITY, OP_IDENTITY_001, OP_IDENTITY_ADMIN, ...), each containing the "contents" of an identity file /private key (either age-format or ssh) ? If that would be ok, I'll volunteer to create and submit it. Whether or not the pipes/stdin issue is considered a bug, I personally would prefer environment variables so keys don't need to be in the file system at all.

@plaidfinch that could address your use case, right?

🤔 It should be possible to unify the implementation with the code in wage where identities are passed to an inner function as an array of Read (ReadableStream in the web-sys case). That implementation could be called for any file-like input, including stdin/pipes, and could be called by rage cli, or WASI, that enumerates environment variables.

from rage.

@stevelr this would address my use case, though I think support for stdin would still be a useful addition.

from rage.

Just noticed this comment that this there are plans for supporting this in the plugin api. I haven't been following that api development so I don't know whether the api is ready to write that plugin, or whether it's blocked waiting for a future capability of the plugin api. I didn't see a current plugin that implements environment variable support.

from rage.

@str4d Are you open to a PR that accepts environment variables with the prefix "OP_IDENTITY" (examples: OP_IDENTITY, OP_IDENTITY_001, OP_IDENTITY_ADMIN, ...), each containing the "contents" of an identity file /private key (either age-format or ssh) ?

No, that is not an approach I will merge into rage. If someone wants a CLI binary that supports that kind of API, they can create it using the age library themselves, or as a trivial script wrapping rage (once #379 is fixed), or via a plugin:

Just noticed this comment that this there are plans for supporting this in the plugin api. I haven't been following that api development so I don't know whether the api is ready to write that plugin, or whether it's blocked waiting for a future capability of the plugin api. I didn't see a current plugin that implements environment variable support.

Yes the plugin APIs should be sufficient to implement a plugin like this now. I am unaware of any such plugin yet, but environment variables given to rage are available to the plugins (they are started as child processes that inherit the parent's environment).

from rage.

Regarding this issue, I suspect that both it and #379 will be fixed once age is changed to not assume it can read the identity files more than once. My preferred approach for that is here: #354 (comment)

from rage.

Cleaning up the issue tracker; this is a duplicate of #177.

from rage.