[Bug 69] Generalize SSH_ASKPASS

[Steven Doerfler]

At 09:20 AM 3/27/2003 +0000, David Woodhouse wrote:
>On Wed, 2003-03-26 at 20:32, Jim Knoble wrote:
>> If you want a separate behavior, that request should be explicit:
>> either an explicit option to ssh-askpass (e.g., 'ssh-askpass --yesno')
>> or (probably better) a separate program (e.g., 'ssh-confirm').
>> 
>> Care to come up with a specification?
>
>Hmmm. We really do have to be careful about backwards compatibility. So
>a separate program probably accompanied by a separate environment
>variable for it (SSH_CONFIRM?) is likely to be the best way forward.

You could retain compatibility without introducing a new program by having
ssh invoke ssh-askpass with an environment variable hinting at the type of
request.  For instance, SSH_ASKPASS_PROMPT_HINT=Y might indicate that this
is a yes/no prompt.

An ssh-askpass program could decide to show Yes/No buttons when it saw such
an environment variable setting.  An ssh-askpass program would be free to
ignore such a hint and always require the user to type YES in a text box,
so an old ssh-askpass would work with a future ssh that supplied an
SSH_ASKPASS_PROMPT_HINT, or vice versa.

Also, the read_passphrase() function that calls ssh-askpass receives a flag
RP_ECHO that tells it whether echoing the user's response is appropriate.
It uses this information when it prompts, but not when it calls an
ssh-askpass program.  The same environment variable could be used to pass
this information along to any ssh-askpass program that wanted to make use
of it.

In more detail, if an ssh-askpass program noticed an
SSH_ASKPASS_PROMPT_HINT environment variable whose value contained the
letter E, it could choose to enable echoing when prompting for a line of
text.  If such an environment variable contained a letter Y, it could
choose to display a Yes/No dialog (and output "yes" or "no" on stdout, just
as now).

Steven Doerfler