Allow custom Touch ID prompt via AGE_PLUGIN_SE_PROMPT env var

[dcosson]

When set, the value of AGE_PLUGIN_SE_PROMPT is used as the LAContext.localizedReason shown in the authentication dialog during decryption. Lets callers display a meaningful description of what's being approved.

[dcosson]

@remko is it possible to get this merged?

It would be very helpful to merge this plus #15 and then do a new homebrew release if possible!

[remko]

This PR changes a lot more than what the description says. This can't be merged in its current form.
I'm not sure yet if I would approve this change at all, I would need to see it in action first to understand how it looks, and what the consequences are for security.

[dcosson]

Ah yeah sorry, some of the other stuff I needed to use my forked version in the interim made it in. I can clean it up but let me know if you're open to the feature at all first.

I find this change helpful, it lets your scripts (or AI agents, as we use it) annotate what they plan to call when the encrypted secret is unlocked. It is purely a UX nicety though, obviously once the script gets the secret it can use it for anything not just the call annotated on the request.

So maybe you could argue this is a bad idea because the annotation could be spoofed and trick you. But in the current state without any annotation listed you still have that same uncertainty of what the secret text will actually be used for when this prompt is presented to you as a user. So I'd argue it doesn't really make this problem any worse, plus users of this plugin don't have to make use of the feature if they prefer not to have that potentially misleading text shown.

[cchepelov]

AGE_PLUGIN_SE_PROMPT is controlled by the caller, so you could indeed spoof by doing this:

AGE_PLUGIN_SE_PROMPT='unlock sandbox, honest!' age -d -i prod.key prod-admin.age

so the prompt shown would be age-plugin se is trying to unlock sandbox, honest! -- with a less in-your-face env var value, it may successfully convince me to approve.

If instead, the name is etched on the key, the caller of age cannot spoof the message:

age-plugin-se keygen --access-control=current-biometry --name "AWS: production" -o named-prod.key
       # --name would be new here

this would result into a message stating age-plugin-se is trying to unlock AWS: production. This would help me much better decide whether to approve it (especially if it pops up in response to an agent trying to do some definitely non-prod task and "helpfully" wandering into prod).

(with the static key-bound name, having a subordinate AGE_PLUGIN_SE_PROMPT makes it harder to spoof:

AGE_PLUGIN_SE_PROMPT='unlock sandbox, honest!' age -d -i named-prod.key prod-admin.age

would result in an Apple-controlled approval box saying: age-plugin-se is trying to unlock AWS: production - unlock sandbox, honest!
This is a discrepancy I as a user would value to act on (deny and immediately search for what's going on).