UX: Document pinentry functionality. how to select a pinentry program.

[vext01]

Having seen this, I was trying to figure out how pinentry support works. Specifically how to choose a different pinentry. Is it possible?

Should this be documented somewhere? In the README perhaps?

[str4d]

rage uses the first binary named pinentry found in the PATH, so you can control which pinentry binary is used by placing the preferred binary earlier in the PATH. If no binary named pinentry can be found in the PATH, rage falls back to a CLI approach; this can be used to "disable" pinentry usage if needed. We could add a section to the main README that documents this, under a "Requesting secrets" heading (since we only use pinentry for requesting passphrases or plugin secrets).

Aside: I'm still trying to decide whether or not to keep pinentry support around. I added it because I thought it would be a predictable existing interface that users would be used to for secret requests, but that hasn't always been the case in the (few) user reports I've had back. I definitely don't want to go adding a bunch of configuration options for it, which would complicate the UX. For now, I think it remains useful enough.

[vext01]

I think it might also be nice to have an environment variable (or similar) to choose a pinentry program.

…

On Tue, 28 Dec 2021, 00:59 str4d, ***@***.***> wrote: rage uses the first binary named pinentry found in the PATH, so you can control which pinentry binary is used by placing the preferred binary earlier in the PATH. If no binary named pinentry can be found in the PATH, rage falls back to a CLI approach; this can be used to "disable" pinentry usage if needed. We could add a section to the main README that documents this, under a "Requesting secrets" heading (since we only use pinentry for requesting passphrases or plugin secrets). Aside: I'm still trying to decide whether or not to keep pinentry support around. I added it because I thought it would be a predictable existing interface that users would be used to for secret requests, but that hasn't always been the case in the (few) user reports I've had back. I definitely don't want to go adding a bunch of configuration options for it, which would complicate the UX. For now, I think it remains useful enough. — Reply to this email directly, view it on GitHub <#280 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAETWG3OXQBPQB3TH4CB5JTUTEDWNANCNFSM5KGPORRA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[str4d]

I finally had time to dig into how GPG configures pinentry, which is only used directly by gpg-agent:

• The pinentry binary can be configured with the --pinentry-program option when starting gpg-agent, or permanently via the pinentry-program option in ~/.gnupg/gpg-agent.conf.
• If a PINENTRY_USER_DATA environment variable is set then gpg2 ensures it gets passed through to gpg-agent and on to the underlying pinentry program (issue).

rage does not have a corresponding agent, and instead calls pinentry directly (if available). So I believe that pinentry should already inherit any environment variables, including PINENTRY_USER_DATA. I still don't want to add config options to rage for this, but I think I could live with a PINENTRY_PROGRAM environment variable that emulates the pinentry-program option for gpg-agent (and would also not be rage-specific, so if in future I decide to remove pinentry, the environment variable can just be ignored).

[str4d]

Closed by #364.