simon-git: putty (pre-0.78): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  bdb3ac9f Restrict -pwfile / -pw to apply to server prompts only.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: pre-0.78
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2022-10-23 14:20:59

commit bdb3ac9f3b80b0c94c05261abc9cbe7b89a9ebea
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=bdb3ac9f3b80b0c94c05261abc9cbe7b89a9ebea;hp=2fbb9284f35ea66a39c1744adc417f346417780c
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Oct 23 14:00:07 2022 +0100

    Restrict -pwfile / -pw to apply to server prompts only.
    
    Jacob spotted that an unused -pwfile input can be accidentally used as
    the answer to Plink's antispoof 'press Return to begin session'
    prompt, which is unintended and confusing.
    
    To fix that, I've made the use of a command-line password conditional
    on p->to_server, the flag in a prompts_t that indicates whether the
    results of the prompts are going to be sent directly to the server or
    consumed locally by PuTTY. (And I've also corrected the setting of
    to_server in the antispoof prompt, which was true when it should have
    been false.)
    
    A side effect of this is that -pwfile will no longer work to provide a
    private-key passphrase, if you're using public-key authentication
    without Pageant. This is deliberate, because if you're doing that on
    purpose then Pageant is a better way to achieve the same thing (or
    else just store the key unencrypted, which is no worse); but in the
    case of a server that sequentially demands public-key _and_ password
    authentication, the new behaviour makes -pwfile apply to the right one
    of the two prompts, i.e. the actual password.

 cmdline.c         | 8 ++++++--
 ssh/connection2.c | 2 +-
 2 files changed, 7 insertions(+), 3 deletions(-)