Permit hands-free CLI usage for --passphrase | -p

[n-hebert]

Hello! 👋 New user to age. Looks great.

One of the things I immediately ran into when trying to use it from BASH for generating multiple keys was that --passphrase wants me to hit enter manually each time.
Even piping < /dev/null into it doesn't seem to work.

I'd be looking to see a --gen-passphrase | -g option which does what age does when the user hits enter and offers no suggested passphrase. (I'm totally open on the naming, it's just a suggestion).

Alternatively, piping /dev/null into age -p could do this by default.

Please let me know if there's an easy work-around!
Thanks.

[n-hebert]

I'm also thinking aloud here... in a perfect world I'd like to pipe in the secret via environment variable, too.
That might be part of the same discussion here.

An AGE_PASSPHRASE environment variable could be hooked up to some secrets and then age could read the passphrase from here.

Again, mostly from a hands-free / CI/CD mindset.

[cipriancraciun]

Strictly related to this topic of passing a passphrase to age via a non-interactive mean, see the following related discussions:

• UX: Missing option for noninteractive use of passwords #256
• UX: Support reading password from file(descriptor) #257
• UX: Make age take a passphrase from a non-terminal source #275

Although I would like to see such a thing happening, Filippo has stated repeatedly he would be inclined against such a possibility. (In a later comment he suggested something related to a plugin that might solve this.)

So, if you would like such a feature, you could try to up-vote one of those discussions (for example #256) and perhaps we'll get such a feature accepted.

[n-hebert]

Thank for this intel @cipriancraciun.
I'm surprised there's any opposition here, but I'll add my votes there.

[keisentraut]

There's a hacky workaround:
I wrote a small tool which generates a deterministic X25519 secret key (="identity") from any passphrase, so you can generate your own random passphrase and then use my tool to derive a key from it. Use on own risk: https://github.com/keisentraut/age-keygen-deterministic

[n-hebert]

I don't see a button to close this discussion but it seems the #256, #257, #275 already cover this.

[n-hebert]

In "talk is cheap, show me the code" fashion, here's what would make me happy as can be!
n-hebert@16ff95a

[cipriancraciun]

Yes, the required changes are minimal, and anyone can patch the upstream code to achieve this. (The issue is more of a "policy" nature than a technical one.)

However, forking and patching means that you'll have to maintain your own fork and always rebase / merge upstream which won't be fun long term...

[n-hebert]

Fully agreed. I'm by no means happy with the tired old purity/sanctity arguments vs raw usability, but this makes it clear what I'm looking for so there's no lack of clarity on requirements 🙂

[yawn]

My expect based workaround is trivial, maybe you can adopt it to your needs: https://github.com/yawn/offkey/blob/406370531c15bfaeba854f28ac6d6a1cd0e4bd08/offkey_test.go#L147

I would, ehem, expect that expect is almost universally available on unix-ish platforms.

[cipriancraciun]

Just out of curiosity I've looked at the line in question and wondered: what if the password does happen to contain a quote? Like say start-of-the-password"; spawn rm -Rf /very-important-folder; send -- "rest-of-the-password, I don't usually have such a password, but who knows...

[yawn]

Not sure on what kinds of passwords this script would choke, I just use it as an integration test helper for a tool build on top of the age cli. You might want to normalize the password when it accepts somewhat arbitrary / UGC input, maybe using base encoding. Or a fixed size hash if it's really unchecked UGC.