UX: Support reading password from file(descriptor)

[iger]

It would be very useful, if age supported reading password from file descriptor/path.
It can be done safely, it would be useful for automation and AFAIU it is the only encryption mode that actually does authenticated encryption.

AFAIK types of usage shown below should be safe. Both can less or more practically be read by the same user, but a more permanent private key would be even easier to read.

age --password-fd <( <<< "$PASS") ...

pwfile=$(mktemp /dev/shm/XXXXXX)
cat > "$pwfile" << EOF
$PASS
EOF
age --password-fd "$pwfile" ...
rm "$pwfile"

[FiloSottile]

See #256 (comment). If this becomes a commonly requested feature we might consider it, and I'd like to hear use cases to better understand how it would be used.

[n-hebert]

Since there are no use-cases immediately posted under this thread I have two from an IT/key management capacity:

1. I have already employed age in a script to massively generate shared disposable/ephemeral private keys, but hit a blocker: the private keys are not passphrase protected, so sharing them to their downstream users requires a fully secure channel. This is besides the fact that I don't want to hit enter once per every user. In the ultimate flow, I provide the key to the user via some semi-secure channel and then dispense with the passphrases in a second far-more-secure channel.
2. I would want to generate a private key in a CI/CD capacity for testing larger programmatic flows involving encrypting files and I don't have human at the keys in those settings. I'm not sure how far this testing could ultimately reach if there are more user-entries required downstream in the flow, as my testing got blocked on the key generation phase.

[cuotos]

I'd like to be able to pipe a password into age for a simple one-line command for decrypting a file and setting env vars (some api tokens). But i want to read the password from the OS's keychain and pass it in to age in a similar way docker login does...

security find-generic-password -w .... | age -d --passphrase-stdin file.age.

[mwgamera]

I want to note that this kind of non-interactive usage is perfectly well supported with keys instead of passwords. Simply store the private key generated with age-keygen in the keychain instead of a password.

echo AGE-SECRET-KEY-(...) | age -i - -d file.age

X25519 keys are short enough that they should easily fit anywhere one might want to store passphrases. Additional upside is that it's also much faster than passphrase key derivation.

[cipriancraciun]

Unfortunately, as I've commented on #256, that doesn't work for example when age is used for full-disk-encryption, because there is no keychain to store the private key into...

---

In the end, I think a dangerous trend will appear, namely more projects that allow one to generate ECDSA private keys from "passwords", and feed those into age, like for example:

read-password | generate-ecdsa-key | age -i - -d encrypted.age

There is already a project like this, one specifically targeting age: https://github.com/keisentraut/age-keygen-deterministic. (And I definitively remember seeing another project on GitHub that generates a generic ECDSA key.)

So, the longer age defers implementing passwords from fd's, more solutions like that would pop-up, many most likely with security holes, that would just negate the security provided by age.

---

All this for what? Just because something might be a "foot-gun" it means we shouldn't provide the option for it?

Here are two possible solutions:

• (A) make the flag clearly indicate that the user is a moron for using it, like for example --yes-i-am-moron-because-i-will-undoubtedly-leak-my-password-which-i-will-provide-on-this-fd; (I will certainly be one of those morons;)
• (B) provide a compile time flag, disabled by default, that will feature-gate that flag; thus anyone wanting that feature could just build age with a simple go build -tags age_with_password_fd github.com/FiloSottile/age; it's much simpler than just creating your own fork;

As I've said, this single missing feature is the reason why I can't just ditch gpg at least for the full-disk-encryption use-case.

[keisentraut]

read-password | generate-ecdsa-key | age -i - -d encrypted.age

Just a remark from the author of age-keygen-deterministic, which I agree shouldn't exist, but it was the easiest way for me...

• I never intended and use it in this way. I generated the secret key once from my passphrase, got the public key and stored only the public key next to the backup script. Only if my house burns down, I will fall back to using this.
• This unfortunately gives up post-quantum-resistency for "nothing". Using a age passphrase (which then does not use X25519, but scrypt) would have been better, but it is not possible from a script.

I would have preferred option (A), too, but this was the most pragmatic way to do it and I think my solution is "good enough" for my private pictures. But I will use your comment as trigger to put some more "do not do this"-disclaimers on my project page.

[mirql]

using "expect"

#520 (comment)

[clach04]

using "expect"

#520 (comment)

This use case does not work for native Microsoft Windows users, where as a command line option would. I'm now using an alternative age implementation because of this.