nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
3c6ab5bbb7
putty-source/windows/wincons.c

433 lines
13 KiB
C
Raw Normal View History

Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
/*
Sprinkle some header comments in various files in an attempt to explain what they're for. [originally from svn r6639]
2006-04-23 18:26:03 +00:00
* wincons.c - various interactive-prompt routines shared between
Various tweaks to header comments to remind me which bits are meant to be platform-independent, etc. [originally from svn r4148]
2004-04-27 12:31:57 +00:00
* the Windows console PuTTY tools
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
*/
#include <stdio.h>
#include <stdlib.h>
#include "putty.h"
#include "storage.h"
#include "ssh.h"
Factor out some common code in {ux,win}cons.c. The assorted host-key and warning prompt messages have no reason to differ between the two platforms, so let's centralise them. Also, while I'm here, some basic support functions that are the same in both modules.
2021-03-13 09:24:17 +00:00
#include "console.h"
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
Ensure our network layer is properly cleaned up before PuTTY exits. Specifically, we explicitly closesocket() all open sockets, which appears to be necessary since otherwise Windows sends RST rather than FIN. I'm _sure_ that's a Windows bug, but there we go. [originally from svn r1574]
2002-03-06 20:13:22 +00:00
void cleanup_exit(int code)
{
/*
* Clean up.
*/
sk_cleanup();
Each platform's implementation of askappend() is no longer required to consult cfg.logxfovr, because it gets done once in logging.c. askappend() is now called only when a question _really_ needs to be asked of the user. Also in this checkin, cleanup_exit() in console.c no longer consults cfg.protocol to decide whether to save the random seed, because random_save_seed() can make that decision for itself and do it better. [originally from svn r2552]
2003-01-12 13:44:35 +00:00
random_save_seed();
Ensure our network layer is properly cleaned up before PuTTY exits. Specifically, we explicitly closesocket() all open sockets, which appears to be necessary since otherwise Windows sends RST rather than FIN. I'm _sure_ that's a Windows bug, but there we go. [originally from svn r1574]
2002-03-06 20:13:22 +00:00
exit(code);
}
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
void console_print_error_msg(const char *prefix, const char *msg)
{
fputs(prefix, stderr);
fputs(": ", stderr);
fputs(msg, stderr);
fputc('\n', stderr);
fflush(stderr);
}
int console_verify_ssh_host_key(
Seat *seat, const char *host, int port,
const char *keytype, char *keystr, char *fingerprint,
void (*callback)(void *ctx, int result), void *ctx)
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
{
int ret;
HANDLE hin;
DWORD savemode, i;
Factor out some common code in {ux,win}cons.c. The assorted host-key and warning prompt messages have no reason to differ between the two platforms, so let's centralise them. Also, while I'm here, some basic support functions that are the same in both modules.
2021-03-13 09:24:17 +00:00
const char *common_fmt, *intro, *prompt;
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
char line[32];
/*
* Verify the key against the registry.
*/
ret = verify_host_key(host, port, keytype, keystr);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (ret == 0) /* success - key matched OK */
return 1;
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (ret == 2) { /* key was different */
Factor out some common code in {ux,win}cons.c. The assorted host-key and warning prompt messages have no reason to differ between the two platforms, so let's centralise them. Also, while I'm here, some basic support functions that are the same in both modules.
2021-03-13 09:24:17 +00:00
common_fmt = hk_wrongmsg_common_fmt;
intro = hk_wrongmsg_interactive_intro;
prompt = hk_wrongmsg_interactive_prompt;
} else { /* key was absent */
common_fmt = hk_absentmsg_common_fmt;
intro = hk_absentmsg_interactive_intro;
prompt = hk_absentmsg_interactive_prompt;
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
}
Factor out some common code in {ux,win}cons.c. The assorted host-key and warning prompt messages have no reason to differ between the two platforms, so let's centralise them. Also, while I'm here, some basic support functions that are the same in both modules.
2021-03-13 09:24:17 +00:00
fprintf(stderr, common_fmt, keytype, fingerprint);
if (console_batch_mode) {
fputs(console_abandoned_msg, stderr);
return 0;
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
}
Factor out some common code in {ux,win}cons.c. The assorted host-key and warning prompt messages have no reason to differ between the two platforms, so let's centralise them. Also, while I'm here, some basic support functions that are the same in both modules.
2021-03-13 09:24:17 +00:00
fputs(intro, stderr);
fflush(stderr);
fputs(prompt, stderr);
fflush(stderr);
line[0] = '\0'; /* fail safe if ReadFile returns no data */
Windows Plink: treat EOF at host key prompt as 'abort connection'. Thanks to Didrik Nordström for pointing out that we currently treated it as 'whatever happened to be in line[0] before ReadFile didn't get any data'.
2017-02-15 06:03:50 +00:00
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
hin = GetStdHandle(STD_INPUT_HANDLE);
GetConsoleMode(hin, &savemode);
SetConsoleMode(hin, (savemode | ENABLE_ECHO_INPUT |
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ENABLE_PROCESSED_INPUT | ENABLE_LINE_INPUT));
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
ReadFile(hin, line, sizeof(line) - 1, &i, NULL);
SetConsoleMode(hin, savemode);
if (line[0] != '\0' && line[0] != '\r' && line[0] != '\n') {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (line[0] == 'y' || line[0] == 'Y')
store_host_key(host, port, keytype, keystr);
Revamp interface to verify_ssh_host_key() and askalg(). Each of them now returns an integer: 0 means cancel the SSH connection and 1 means continue with it. Additionally, they can return -1, which means `front end has set an asynchronous alert box in motion, please wait to be called back with the result', and each one is passed a callback function pointer and context for this purpose. I have not yet done the same to askappend() yet, because it will take a certain amount of reorganisation of logging.c. Importantly, this checkin means the host key dialog box now works on OS X. [originally from svn r5330]
2005-02-17 18:34:24 +00:00
return 1;
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
} else {
Factor out some common code in {ux,win}cons.c. The assorted host-key and warning prompt messages have no reason to differ between the two platforms, so let's centralise them. Also, while I'm here, some basic support functions that are the same in both modules.
2021-03-13 09:24:17 +00:00
fputs(console_abandoned_msg, stderr);
Revamp interface to verify_ssh_host_key() and askalg(). Each of them now returns an integer: 0 means cancel the SSH connection and 1 means continue with it. Additionally, they can return -1, which means `front end has set an asynchronous alert box in motion, please wait to be called back with the result', and each one is passed a callback function pointer and context for this purpose. I have not yet done the same to askappend() yet, because it will take a certain amount of reorganisation of logging.c. Importantly, this checkin means the host key dialog box now works on OS X. [originally from svn r5330]
2005-02-17 18:34:24 +00:00
return 0;
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
}
}
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
int console_confirm_weak_crypto_primitive(
Seat *seat, const char *algtype, const char *algname,
void (*callback)(void *ctx, int result), void *ctx)
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
{
HANDLE hin;
DWORD savemode, i;
char line[32];
Factor out some common code in {ux,win}cons.c. The assorted host-key and warning prompt messages have no reason to differ between the two platforms, so let's centralise them. Also, while I'm here, some basic support functions that are the same in both modules.
2021-03-13 09:24:17 +00:00
fprintf(stderr, weakcrypto_msg_common_fmt, algtype, algname);
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
if (console_batch_mode) {
Factor out some common code in {ux,win}cons.c. The assorted host-key and warning prompt messages have no reason to differ between the two platforms, so let's centralise them. Also, while I'm here, some basic support functions that are the same in both modules.
2021-03-13 09:24:17 +00:00
fputs(console_abandoned_msg, stderr);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
}
Factor out some common code in {ux,win}cons.c. The assorted host-key and warning prompt messages have no reason to differ between the two platforms, so let's centralise them. Also, while I'm here, some basic support functions that are the same in both modules.
2021-03-13 09:24:17 +00:00
fputs(console_continue_prompt, stderr);
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
fflush(stderr);
hin = GetStdHandle(STD_INPUT_HANDLE);
GetConsoleMode(hin, &savemode);
SetConsoleMode(hin, (savemode | ENABLE_ECHO_INPUT |
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ENABLE_PROCESSED_INPUT | ENABLE_LINE_INPUT));
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
ReadFile(hin, line, sizeof(line) - 1, &i, NULL);
SetConsoleMode(hin, savemode);
if (line[0] == 'y' || line[0] == 'Y') {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 1;
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
} else {
Factor out some common code in {ux,win}cons.c. The assorted host-key and warning prompt messages have no reason to differ between the two platforms, so let's centralise them. Also, while I'm here, some basic support functions that are the same in both modules.
2021-03-13 09:24:17 +00:00
fputs(console_abandoned_msg, stderr);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
}
}
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
int console_confirm_weak_cached_hostkey(
Seat *seat, const char *algname, const char *betteralgs,
void (*callback)(void *ctx, int result), void *ctx)
Special host key warning when a better key exists. If you're connecting to a new server and it _only_ provides host key types you've configured to be below the warning threshold, it's OK to give the standard askalg() message. But if you've newly demoted a host key type and now reconnect to some server for which that type was the best key you had cached, the askalg() wording isn't really appropriate (it's not that the key we've settled on is the first type _supported by the server_, it's that it's the first type _cached by us_), and also it's potentially helpful to list the better algorithms so that the user can pick one to cross-certify.
2016-03-27 17:08:49 +00:00
{
HANDLE hin;
DWORD savemode, i;
char line[32];
Factor out some common code in {ux,win}cons.c. The assorted host-key and warning prompt messages have no reason to differ between the two platforms, so let's centralise them. Also, while I'm here, some basic support functions that are the same in both modules.
2021-03-13 09:24:17 +00:00
fprintf(stderr, weakhk_msg_common_fmt, algname, betteralgs);
Special host key warning when a better key exists. If you're connecting to a new server and it _only_ provides host key types you've configured to be below the warning threshold, it's OK to give the standard askalg() message. But if you've newly demoted a host key type and now reconnect to some server for which that type was the best key you had cached, the askalg() wording isn't really appropriate (it's not that the key we've settled on is the first type _supported by the server_, it's that it's the first type _cached by us_), and also it's potentially helpful to list the better algorithms so that the user can pick one to cross-certify.
2016-03-27 17:08:49 +00:00
if (console_batch_mode) {
Factor out some common code in {ux,win}cons.c. The assorted host-key and warning prompt messages have no reason to differ between the two platforms, so let's centralise them. Also, while I'm here, some basic support functions that are the same in both modules.
2021-03-13 09:24:17 +00:00
fputs(console_abandoned_msg, stderr);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
Special host key warning when a better key exists. If you're connecting to a new server and it _only_ provides host key types you've configured to be below the warning threshold, it's OK to give the standard askalg() message. But if you've newly demoted a host key type and now reconnect to some server for which that type was the best key you had cached, the askalg() wording isn't really appropriate (it's not that the key we've settled on is the first type _supported by the server_, it's that it's the first type _cached by us_), and also it's potentially helpful to list the better algorithms so that the user can pick one to cross-certify.
2016-03-27 17:08:49 +00:00
}
Factor out some common code in {ux,win}cons.c. The assorted host-key and warning prompt messages have no reason to differ between the two platforms, so let's centralise them. Also, while I'm here, some basic support functions that are the same in both modules.
2021-03-13 09:24:17 +00:00
fputs(console_continue_prompt, stderr);
Special host key warning when a better key exists. If you're connecting to a new server and it _only_ provides host key types you've configured to be below the warning threshold, it's OK to give the standard askalg() message. But if you've newly demoted a host key type and now reconnect to some server for which that type was the best key you had cached, the askalg() wording isn't really appropriate (it's not that the key we've settled on is the first type _supported by the server_, it's that it's the first type _cached by us_), and also it's potentially helpful to list the better algorithms so that the user can pick one to cross-certify.
2016-03-27 17:08:49 +00:00
fflush(stderr);
hin = GetStdHandle(STD_INPUT_HANDLE);
GetConsoleMode(hin, &savemode);
SetConsoleMode(hin, (savemode | ENABLE_ECHO_INPUT |
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ENABLE_PROCESSED_INPUT | ENABLE_LINE_INPUT));
Special host key warning when a better key exists. If you're connecting to a new server and it _only_ provides host key types you've configured to be below the warning threshold, it's OK to give the standard askalg() message. But if you've newly demoted a host key type and now reconnect to some server for which that type was the best key you had cached, the askalg() wording isn't really appropriate (it's not that the key we've settled on is the first type _supported by the server_, it's that it's the first type _cached by us_), and also it's potentially helpful to list the better algorithms so that the user can pick one to cross-certify.
2016-03-27 17:08:49 +00:00
ReadFile(hin, line, sizeof(line) - 1, &i, NULL);
SetConsoleMode(hin, savemode);
if (line[0] == 'y' || line[0] == 'Y') {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 1;
Special host key warning when a better key exists. If you're connecting to a new server and it _only_ provides host key types you've configured to be below the warning threshold, it's OK to give the standard askalg() message. But if you've newly demoted a host key type and now reconnect to some server for which that type was the best key you had cached, the askalg() wording isn't really appropriate (it's not that the key we've settled on is the first type _supported by the server_, it's that it's the first type _cached by us_), and also it's potentially helpful to list the better algorithms so that the user can pick one to cross-certify.
2016-03-27 17:08:49 +00:00
} else {
Factor out some common code in {ux,win}cons.c. The assorted host-key and warning prompt messages have no reason to differ between the two platforms, so let's centralise them. Also, while I'm here, some basic support functions that are the same in both modules.
2021-03-13 09:24:17 +00:00
fputs(console_abandoned_msg, stderr);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
Special host key warning when a better key exists. If you're connecting to a new server and it _only_ provides host key types you've configured to be below the warning threshold, it's OK to give the standard askalg() message. But if you've newly demoted a host key type and now reconnect to some server for which that type was the best key you had cached, the askalg() wording isn't really appropriate (it's not that the key we've settled on is the first type _supported by the server_, it's that it's the first type _cached by us_), and also it's potentially helpful to list the better algorithms so that the user can pick one to cross-certify.
2016-03-27 17:08:49 +00:00
}
}
Add an interactive anti-spoofing prompt in Plink. At the point when we change over the seat's trust status to untrusted for the last time, to finish authentication, Plink will now present a final interactive prompt saying 'Press Return to begin session'. This is a hint that anything after that that resembles an auth prompt should be treated with suspicion, because _PuTTY_ thinks it's finished authenticating. This is of course an annoying inconvenience for interactive users, so I've tried to reduce its impact as much as I can. It doesn't happen in GUI PuTTY at all (because the trust sigil system is used instead); it doesn't happen if you use plink -batch (because then the user already knows that they _never_ expect an interactive prompt); and it doesn't happen if Plink's standard input is being redirected from anywhere other than the terminal / console (because then it would be pointless for the server to try to scam passphrases out of the user anyway, since the user isn't in a position to enter one in response to a spoof prompt). So it should only happen to people who are using Plink in a terminal for interactive login purposes, and that's not _really_ what I ever intended Plink to be used for (which is why it's never had any out-of-band control UI like OpenSSH's ~ system). If anyone _still_ doesn't like this new prompt, it can also be turned off using the new -no-antispoof flag, if the user is willing to knowingly assume the risk.
2019-03-10 14:42:33 +00:00
bool is_interactive(void)
{
return is_console_handle(GetStdHandle(STD_INPUT_HANDLE));
}
bool console_antispoof_prompt = true;
Seat method to set the current trust status. In terminal-based GUI applications, this is passed through to term_set_trust_status, to toggle whether lines are prefixed with the new trust sigil. In console applications, the function returns false, indicating to the backend that it should employ some other technique for spoofing protection.
2019-03-10 14:42:11 +00:00
bool console_set_trust_status(Seat *seat, bool trusted)
{
Add an interactive anti-spoofing prompt in Plink. At the point when we change over the seat's trust status to untrusted for the last time, to finish authentication, Plink will now present a final interactive prompt saying 'Press Return to begin session'. This is a hint that anything after that that resembles an auth prompt should be treated with suspicion, because _PuTTY_ thinks it's finished authenticating. This is of course an annoying inconvenience for interactive users, so I've tried to reduce its impact as much as I can. It doesn't happen in GUI PuTTY at all (because the trust sigil system is used instead); it doesn't happen if you use plink -batch (because then the user already knows that they _never_ expect an interactive prompt); and it doesn't happen if Plink's standard input is being redirected from anywhere other than the terminal / console (because then it would be pointless for the server to try to scam passphrases out of the user anyway, since the user isn't in a position to enter one in response to a spoof prompt). So it should only happen to people who are using Plink in a terminal for interactive login purposes, and that's not _really_ what I ever intended Plink to be used for (which is why it's never had any out-of-band control UI like OpenSSH's ~ system). If anyone _still_ doesn't like this new prompt, it can also be turned off using the new -no-antispoof flag, if the user is willing to knowingly assume the risk.
2019-03-10 14:42:33 +00:00
if (console_batch_mode || !is_interactive() || !console_antispoof_prompt) {
/*
* In batch mode, we don't need to worry about the server
* mimicking our interactive authentication, because the user
* already knows not to expect any.
*
* If standard input isn't connected to a terminal, likewise,
* because even if the server did send a spoof authentication
* prompt, the user couldn't respond to it via the terminal
* anyway.
*
* We also vacuously return success if the user has purposely
* disabled the antispoof prompt.
*/
return true;
}
Seat method to set the current trust status. In terminal-based GUI applications, this is passed through to term_set_trust_status, to toggle whether lines are prefixed with the new trust sigil. In console applications, the function returns false, indicating to the backend that it should employ some other technique for spoofing protection.
2019-03-10 14:42:11 +00:00
return false;
}
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
/*
* Ask whether to wipe a session log file before writing to it.
* Returns 2 for wipe, 1 for append, 0 for cancel (don't log).
*/
Make wincons logging-related functions non-static. Since they're declared thus in putty.h and needed in clicons.c (as of d20d3b20fd).
2020-01-31 09:38:36 +00:00
int console_askappend(LogPolicy *lp, Filename *filename,
void (*callback)(void *ctx, int result), void *ctx)
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
{
HANDLE hin;
DWORD savemode, i;
static const char msgtemplate[] =
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"The session log file \"%.*s\" already exists.\n"
"You can overwrite it with a new session log,\n"
"append your session log to the end of it,\n"
"or disable session logging for this session.\n"
"Enter \"y\" to wipe the file, \"n\" to append to it,\n"
"or just press Return to disable logging.\n"
"Wipe the log file? (y/n, Return cancels logging) ";
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
static const char msgtemplate_batch[] =
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"The session log file \"%.*s\" already exists.\n"
"Logging will not be enabled.\n";
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
char line[32];
if (console_batch_mode) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fprintf(stderr, msgtemplate_batch, FILENAME_MAX, filename->path);
fflush(stderr);
return 0;
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
}
Turn 'Filename' into a dynamically allocated type with no arbitrary length limit, just as I did to FontSpec yesterday. [originally from svn r9316]
2011-10-02 11:01:57 +00:00
fprintf(stderr, msgtemplate, FILENAME_MAX, filename->path);
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
fflush(stderr);
hin = GetStdHandle(STD_INPUT_HANDLE);
GetConsoleMode(hin, &savemode);
SetConsoleMode(hin, (savemode | ENABLE_ECHO_INPUT |
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ENABLE_PROCESSED_INPUT | ENABLE_LINE_INPUT));
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
ReadFile(hin, line, sizeof(line) - 1, &i, NULL);
SetConsoleMode(hin, savemode);
if (line[0] == 'y' || line[0] == 'Y')
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 2;
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
else if (line[0] == 'n' || line[0] == 'N')
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 1;
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
}
/*
* Warn about the obsolescent key file format.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Yet more global-removal. The static variables in logging.c are now absent, and also (I think) all the frontend request functions (such as request_resize) take a context pointer, so that multiple windows can be handled sensibly. I wouldn't swear to this, but I _think_ that only leaves the Unicode stuff as the last stubborn holdout. [originally from svn r2147]
2002-10-26 12:58:13 +00:00
* Uniquely among these functions, this one does _not_ expect a
* frontend handle. This means that if PuTTY is ported to a
* platform which requires frontend handles, this function will be
* an anomaly. Fortunately, the problem it addresses will not have
* been present on that platform, so it can plausibly be
* implemented as an empty function.
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
*/
void old_keyfile_warning(void)
{
static const char message[] =
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"You are loading an SSH-2 private key which has an\n"
"old version of the file format. This means your key\n"
"file is not fully tamperproof. Future versions of\n"
"PuTTY may stop supporting this private key format,\n"
"so we recommend you convert your key to the new\n"
"format.\n"
"\n"
"Once the key is loaded into PuTTYgen, you can perform\n"
"this conversion simply by saving it again.\n";
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
fputs(message, stderr);
}
Try to make our PGP signing more useful: * All the PuTTY tools for Windows and Unix now contain the fingerprints of the Master Keys. The method for accessing them is crude but universal: a new "-pgpfp" command-line option. (Except Unix PuTTYgen, which takes "--pgpfp" just to be awkward.) * Move the key policy discussion from putty-website/keys.html to putty/doc/pgpkeys.but, and autogenerate the former from the latter. Also tweak the text somewhat and include the fingerprints of the Master Keys themselves. (I've merged the existing autogeneration scripts into a single new one; I've left the old scripts and keys.html around until such time as the webmonster reviews the changes and plumbs in the new script; he should remove the old files then.) [originally from svn r5524] [this svn revision also touched putty-website]
2005-03-19 02:26:58 +00:00
/*
* Display the fingerprints of the PGP Master Keys to the user.
*/
void pgp_fingerprints(void)
{
fputs("These are the fingerprints of the PuTTY PGP Master Keys. They can\n"
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"be used to establish a trust path from this executable to another\n"
"one. See the manual for more information.\n"
"(Note: these fingerprints have nothing to do with SSH!)\n"
"\n"
"PuTTY Master Key as of " PGP_MASTER_KEY_YEAR
GPG key rollover. This commit adds the new ids and fingerprints in the keys appendix of the manual, and moves the old ones down into the historic-keys section. I've tweaked a few pieces of wording for ongoing use, so that they don't imply a specific number of past key rollovers. The -pgpfp option in all the tools now shows the new Master Key fingerprint and the previous (2015) one. I've adjusted all the uses of the #defines in putty.h so that future rollovers should only have to modify the #defines themselves. Most importantly, sign.sh bakes in the ids of the current release and snapshot keys, so that snapshots will automatically be signed with the new snapshot key and the -r option will invoke the new release key.
2018-08-25 13:36:25 +00:00
" (" PGP_MASTER_KEY_DETAILS "):\n"
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
" " PGP_MASTER_KEY_FP "\n\n"
"Previous Master Key (" PGP_PREV_MASTER_KEY_YEAR
GPG key rollover. This commit adds the new ids and fingerprints in the keys appendix of the manual, and moves the old ones down into the historic-keys section. I've tweaked a few pieces of wording for ongoing use, so that they don't imply a specific number of past key rollovers. The -pgpfp option in all the tools now shows the new Master Key fingerprint and the previous (2015) one. I've adjusted all the uses of the #defines in putty.h so that future rollovers should only have to modify the #defines themselves. Most importantly, sign.sh bakes in the ids of the current release and snapshot keys, so that snapshots will automatically be signed with the new snapshot key and the -r option will invoke the new release key.
2018-08-25 13:36:25 +00:00
", " PGP_PREV_MASTER_KEY_DETAILS "):\n"
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
" " PGP_PREV_MASTER_KEY_FP "\n", stdout);
Try to make our PGP signing more useful: * All the PuTTY tools for Windows and Unix now contain the fingerprints of the Master Keys. The method for accessing them is crude but universal: a new "-pgpfp" command-line option. (Except Unix PuTTYgen, which takes "--pgpfp" just to be awkward.) * Move the key policy discussion from putty-website/keys.html to putty/doc/pgpkeys.but, and autogenerate the former from the latter. Also tweak the text somewhat and include the fingerprints of the Master Keys themselves. (I've merged the existing autogeneration scripts into a single new one; I've left the old scripts and keys.html around until such time as the webmonster reviews the changes and plumbs in the new script; he should remove the old files then.) [originally from svn r5524] [this svn revision also touched putty-website]
2005-03-19 02:26:58 +00:00
}
Make wincons logging-related functions non-static. Since they're declared thus in putty.h and needed in clicons.c (as of d20d3b20fd).
2020-01-31 09:38:36 +00:00
void console_logging_error(LogPolicy *lp, const char *string)
Fix "-v" in the Windows console utilities (plink, pscp, psftp). I'm not convinced I've done this the right way (I've introduced a static for logctx in console.c) but it will do for now. [originally from svn r2674]
2003-01-21 19:18:06 +00:00
{
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
/* Ordinary Event Log entries are displayed in the same way as
* logging errors, but only in verbose mode */
fprintf(stderr, "%s\n", string);
fflush(stderr);
Fix "-v" in the Windows console utilities (plink, pscp, psftp). I'm not convinced I've done this the right way (I've introduced a static for logctx in console.c) but it will do for now. [originally from svn r2674]
2003-01-21 19:18:06 +00:00
}
Make wincons logging-related functions non-static. Since they're declared thus in putty.h and needed in clicons.c (as of d20d3b20fd).
2020-01-31 09:38:36 +00:00
void console_eventlog(LogPolicy *lp, const char *string)
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
{
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
/* Ordinary Event Log entries are displayed in the same way as
* logging errors, but only in verbose mode */
Remove FLAG_VERBOSE. The global 'int flags' has always been an ugly feature of this code base, and I suddenly thought that perhaps it's time to start throwing it out, one flag at a time, until it's totally unused. My first target is FLAG_VERBOSE. This was usually set by cmdline.c when it saw a -v option on the program's command line, except that GUI PuTTY itself sets it unconditionally on startup. And then various bits of the code would check it in order to decide whether to print a given message. In the current system of front-end abstraction traits, there's no _one_ place that I can move it to. But there are two: every place that checked FLAG_VERBOSE has access to either a Seat or a LogPolicy. So now each of those traits has a query method for 'do I want verbose messages?'. A good effect of this is that subsidiary Seats, like the ones used in Uppity for the main SSH server module itself and the server end of shell channels, now get to have their own verbosity setting instead of inheriting the one global one. In fact I don't expect any code using those Seats to be generating any messages at all, but if that changes later, we'll have a way to control it. (Who knows, perhaps logging in Uppity might become a thing.) As part of this cleanup, I've added a new flag to cmdline_tooltype, called TOOLTYPE_NO_VERBOSE_OPTION. The unconditionally-verbose tools now set that, and it has the effect of making cmdline.c disallow -v completely. So where 'putty -v' would previously have been silently ignored ("I was already verbose"), it's now an error, reminding you that that option doesn't actually do anything. Finally, the 'default_logpolicy' provided by uxcons.c and wincons.c (with identical definitions) has had to move into a new file of its own, because now it has to ask cmdline.c for the verbosity setting as well as asking console.c for the rest of its methods. So there's a new file clicons.c which can only be included by programs that link against both cmdline.c _and_ one of the *cons.c, and I've renamed the logpolicy to reflect that.
2020-01-30 06:40:21 +00:00
if (lp_verbose(lp))
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 18:26:18 +00:00
console_logging_error(lp, string);
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
}
Revise the API for seat_stripctrl_new. Now instead of taking raw arguments to configure the output StripCtrlChars with, it takes an enumerated value giving the context of what's being sanitised, and allows the seat to decide what the output parameters for that context should be. The only context currently used is SIC_BANNER (SSH login banners). I've also added a not-yet-used one for keyboard-interactive prompts.
2019-03-07 08:19:38 +00:00
StripCtrlChars *console_stripctrl_new(
Seat *seat, BinarySink *bs_out, SeatInteractionContext sic)
Add a Seat vtable method to get a stripctrl. If centralised code like the SSH implementation wants to sanitise escape sequences out of a piece of server-provided text, it will need to do it by making a locale-based StripCtrlChars if it's running in a console context, or a Terminal-based one if it's in a GUI terminal- window application. All the other changes of behaviour needed between those two contexts are handled by providing reconfigurable methods in the Seat vtable; this one is no different. So now there's a new method in the Seat vtable that will construct a StripCtrlChars appropriate to that kind of seat. Terminal-window seats (gtkwin.c, window.c) implement it by calling the new stripctrl_new_term(), and console ones use the locale- based stripctrl_new().
2019-03-05 21:13:00 +00:00
{
Revise the API for seat_stripctrl_new. Now instead of taking raw arguments to configure the output StripCtrlChars with, it takes an enumerated value giving the context of what's being sanitised, and allows the seat to decide what the output parameters for that context should be. The only context currently used is SIC_BANNER (SSH login banners). I've also added a not-yet-used one for keyboard-interactive prompts.
2019-03-07 08:19:38 +00:00
return stripctrl_new(bs_out, false, 0);
Add a Seat vtable method to get a stripctrl. If centralised code like the SSH implementation wants to sanitise escape sequences out of a piece of server-provided text, it will need to do it by making a locale-based StripCtrlChars if it's running in a console context, or a Terminal-based one if it's in a GUI terminal- window application. All the other changes of behaviour needed between those two contexts are handled by providing reconfigurable methods in the Seat vtable; this one is no different. So now there's a new method in the Seat vtable that will construct a StripCtrlChars appropriate to that kind of seat. Terminal-window seats (gtkwin.c, window.c) implement it by calling the new stripctrl_new_term(), and console ones use the locale- based stripctrl_new().
2019-03-05 21:13:00 +00:00
}
Move sanitisation of k-i prompts into the SSH code. Now, instead of each seat's prompt-handling function doing the control-char sanitisation of prompt text, the SSH code does it. This means we can do it differently depending on the prompt. In particular, prompts _we_ generate (e.g. a genuine request for your private key's passphrase) are not sanitised; but prompts coming from the server (in keyboard-interactive mode, or its more restricted SSH-1 analogues, TIS and CryptoCard) are not only sanitised but also line-length limited and surrounded by uncounterfeitable headers, like I've just done to the authentication banners. This should mean that if a malicious server tries to fake the local passphrase prompt (perhaps because it's somehow already got a copy of your _encrypted_ private key), you can tell the difference.
2019-03-09 15:51:38 +00:00
static void console_write(HANDLE hout, ptrlen data)
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
{
DWORD dummy;
Move sanitisation of k-i prompts into the SSH code. Now, instead of each seat's prompt-handling function doing the control-char sanitisation of prompt text, the SSH code does it. This means we can do it differently depending on the prompt. In particular, prompts _we_ generate (e.g. a genuine request for your private key's passphrase) are not sanitised; but prompts coming from the server (in keyboard-interactive mode, or its more restricted SSH-1 analogues, TIS and CryptoCard) are not only sanitised but also line-length limited and surrounded by uncounterfeitable headers, like I've just done to the authentication banners. This should mean that if a malicious server tries to fake the local passphrase prompt (perhaps because it's somehow already got a copy of your _encrypted_ private key), you can tell the difference.
2019-03-09 15:51:38 +00:00
WriteFile(hout, data.ptr, data.len, &dummy, NULL);
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
}
Remove unused params from console_get_userpass_input. NFC: this is a preliminary refactoring, intended to make my life easier when I start changing around the APIs used to pass user keyboard input around. The fewer functions even _have_ such an API, the less I'll have to do at that point.
2018-05-18 06:22:56 +00:00
int console_get_userpass_input(prompts_t *p)
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
{
Fix a few compiler warnings from MinGW. A few variables that gcc couldn't tell I'd initialised on all the important paths, a variable that didn't really need to be there anyway, and yet another use of GET_WINDOWS_FUNCTION_NO_TYPECHECK.
2018-06-03 20:48:08 +00:00
HANDLE hin = INVALID_HANDLE_VALUE, hout = INVALID_HANDLE_VALUE;
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
size_t curr_prompt;
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
/*
* Zero all the results, in case we abort half-way through.
*/
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int i;
for (i = 0; i < (int)p->n_prompts; i++)
While I'm crusading against arbitrary limits, here's a redesign of prompt_t to arrange that the buffer in which each prompt is stored can be reallocated larger during the input process. [originally from svn r9317]
2011-10-02 11:50:45 +00:00
prompt_set_result(p->prompts[i], "");
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
}
Handle more gracefully the possibility of a keyboard-interactive prompts packet containing no actual prompts (perhaps due to odd server organisation, or perhaps so it can print a banner message and do nothing else). Previously, the get_userpass_input functions always returned failure when in '-batch' mode, even in this case where no actual input would be required. [originally from svn r8490]
2009-03-03 18:35:53 +00:00
/*
* The prompts_t might contain a message to be displayed but no
* actual prompt. More usually, though, it will contain
* questions that the user needs to answer, in which case we
* need to ensure that we're able to get the answers.
*/
if (p->n_prompts) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (console_batch_mode)
return 0;
hin = GetStdHandle(STD_INPUT_HANDLE);
if (hin == INVALID_HANDLE_VALUE) {
fprintf(stderr, "Cannot get standard input handle\n");
cleanup_exit(1);
}
Handle more gracefully the possibility of a keyboard-interactive prompts packet containing no actual prompts (perhaps due to odd server organisation, or perhaps so it can print a banner message and do nothing else). Previously, the get_userpass_input functions always returned failure when in '-batch' mode, even in this case where no actual input would be required. [originally from svn r8490]
2009-03-03 18:35:53 +00:00
}
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
Handle more gracefully the possibility of a keyboard-interactive prompts packet containing no actual prompts (perhaps due to odd server organisation, or perhaps so it can print a banner message and do nothing else). Previously, the get_userpass_input functions always returned failure when in '-batch' mode, even in this case where no actual input would be required. [originally from svn r8490]
2009-03-03 18:35:53 +00:00
/*
* And if we have anything to print, we need standard output.
*/
if ((p->name_reqd && p->name) || p->instruction || p->n_prompts) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
hout = GetStdHandle(STD_OUTPUT_HANDLE);
if (hout == INVALID_HANDLE_VALUE) {
fprintf(stderr, "Cannot get standard output handle\n");
cleanup_exit(1);
}
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
}
/*
* Preamble.
*/
/* We only print the `name' caption if we have to... */
if (p->name_reqd && p->name) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ptrlen plname = ptrlen_from_asciz(p->name);
console_write(hout, plname);
Move sanitisation of k-i prompts into the SSH code. Now, instead of each seat's prompt-handling function doing the control-char sanitisation of prompt text, the SSH code does it. This means we can do it differently depending on the prompt. In particular, prompts _we_ generate (e.g. a genuine request for your private key's passphrase) are not sanitised; but prompts coming from the server (in keyboard-interactive mode, or its more restricted SSH-1 analogues, TIS and CryptoCard) are not only sanitised but also line-length limited and surrounded by uncounterfeitable headers, like I've just done to the authentication banners. This should mean that if a malicious server tries to fake the local passphrase prompt (perhaps because it's somehow already got a copy of your _encrypted_ private key), you can tell the difference.
2019-03-09 15:51:38 +00:00
if (!ptrlen_endswith(plname, PTRLEN_LITERAL("\n"), NULL))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
console_write(hout, PTRLEN_LITERAL("\n"));
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
}
/* ...but we always print any `instruction'. */
if (p->instruction) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ptrlen plinst = ptrlen_from_asciz(p->instruction);
console_write(hout, plinst);
Move sanitisation of k-i prompts into the SSH code. Now, instead of each seat's prompt-handling function doing the control-char sanitisation of prompt text, the SSH code does it. This means we can do it differently depending on the prompt. In particular, prompts _we_ generate (e.g. a genuine request for your private key's passphrase) are not sanitised; but prompts coming from the server (in keyboard-interactive mode, or its more restricted SSH-1 analogues, TIS and CryptoCard) are not only sanitised but also line-length limited and surrounded by uncounterfeitable headers, like I've just done to the authentication banners. This should mean that if a malicious server tries to fake the local passphrase prompt (perhaps because it's somehow already got a copy of your _encrypted_ private key), you can tell the difference.
2019-03-09 15:51:38 +00:00
if (!ptrlen_endswith(plinst, PTRLEN_LITERAL("\n"), NULL))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
console_write(hout, PTRLEN_LITERAL("\n"));
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
}
for (curr_prompt = 0; curr_prompt < p->n_prompts; curr_prompt++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
DWORD savemode, newmode;
prompt_t *pr = p->prompts[curr_prompt];
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GetConsoleMode(hin, &savemode);
newmode = savemode | ENABLE_PROCESSED_INPUT | ENABLE_LINE_INPUT;
if (!pr->echo)
newmode &= ~ENABLE_ECHO_INPUT;
else
newmode |= ENABLE_ECHO_INPUT;
SetConsoleMode(hin, newmode);
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
console_write(hout, ptrlen_from_asciz(pr->prompt));
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
Use strbuf to store results in prompts_t. UBsan pointed out another memcpy from NULL (again with length 0) in the prompts_t system. When I looked at it, I realised that firstly prompt_ensure_result_size was an early not-so-good implementation of sgrowarray_nm that would benefit from being replaced with a call to the real one, and secondly, the whole system for storing prompt results should really have been replaced with strbufs with the no-move option, because that's doing all the same jobs better. So, now each prompt_t holds a strbuf in place of its previous manually managed string. prompt_ensure_result_size is gone (the console prompt-reading functions use strbuf_append, and everything else just adds to the strbuf in the usual marshal.c way). New functions exist to retrieve a prompt_t's result, either by reference or copied.
2020-01-21 20:19:47 +00:00
bool failed = false;
While I'm crusading against arbitrary limits, here's a redesign of prompt_t to arrange that the buffer in which each prompt is stored can be reallocated larger during the input process. [originally from svn r9317]
2011-10-02 11:50:45 +00:00
while (1) {
Work around console I/O size limit on Windows 7. A user reports that the ReadFile call in console_get_userpass_input fails with ERROR_NOT_ENOUGH_MEMORY on Windows 7, and further reports that this problem only happens if you tell ReadFile to read more than 31366 bytes in a single call. That seems to be a thing that other people have found as well: I turned up a similar workaround in Ruby's Win32 support module, except that there it's for WriteConsole. So I'm reducing my arbitrary read size of 64K to 16K, which is well under that limit. This issue became noticeable in PuTTY as of the recent commit cd6bc14f0, which reworked console_get_userpass_input to use strbufs. Previously we were trying to read an amount proportional to the existing size of the buffer, so as to grow the buffer exponentially to save quadratic-time reallocation. That was OK in practice, since the initial read size was nice and small. But in principle, the same bug was present in that version of the code, just latent - if we'd ever been called on to read a _really large_ amount of data, then _eventually_ the input size parameter to ReadFile would have grown beyond that mysterious limit!
2020-01-26 09:50:07 +00:00
/*
* Amount of data to try to read from the console in one
* go. This isn't completely arbitrary: a user reported
* that trying to read more than 31366 bytes at a time
* would fail with ERROR_NOT_ENOUGH_MEMORY on Windows 7,
* and Ruby's Win32 support module has evidence of a
* similar workaround:
*
* https://github.com/ruby/ruby/blob/0aa5195262d4193d3accf3e6b9bad236238b816b/win32/win32.c#L6842
*
* To keep things simple, I stick with a nice round power
* of 2 rather than trying to go to the very limit of that
* bug. (We're typically reading user passphrases and the
* like here, so even this much is overkill really.)
*/
DWORD toread = 16384;
Use strbuf to store results in prompts_t. UBsan pointed out another memcpy from NULL (again with length 0) in the prompts_t system. When I looked at it, I realised that firstly prompt_ensure_result_size was an early not-so-good implementation of sgrowarray_nm that would benefit from being replaced with a call to the real one, and secondly, the whole system for storing prompt results should really have been replaced with strbufs with the no-move option, because that's doing all the same jobs better. So, now each prompt_t holds a strbuf in place of its previous manually managed string. prompt_ensure_result_size is gone (the console prompt-reading functions use strbuf_append, and everything else just adds to the strbuf in the usual marshal.c way). New functions exist to retrieve a prompt_t's result, either by reference or copied.
2020-01-21 20:19:47 +00:00
size_t prev_result_len = pr->result->len;
void *ptr = strbuf_append(pr->result, toread);
While I'm crusading against arbitrary limits, here's a redesign of prompt_t to arrange that the buffer in which each prompt is stored can be reallocated larger during the input process. [originally from svn r9317]
2011-10-02 11:50:45 +00:00
Use strbuf to store results in prompts_t. UBsan pointed out another memcpy from NULL (again with length 0) in the prompts_t system. When I looked at it, I realised that firstly prompt_ensure_result_size was an early not-so-good implementation of sgrowarray_nm that would benefit from being replaced with a call to the real one, and secondly, the whole system for storing prompt results should really have been replaced with strbufs with the no-move option, because that's doing all the same jobs better. So, now each prompt_t holds a strbuf in place of its previous manually managed string. prompt_ensure_result_size is gone (the console prompt-reading functions use strbuf_append, and everything else just adds to the strbuf in the usual marshal.c way). New functions exist to retrieve a prompt_t's result, either by reference or copied.
2020-01-21 20:19:47 +00:00
DWORD ret = 0;
if (!ReadFile(hin, ptr, toread, &ret, NULL) || ret == 0) {
failed = true;
While I'm crusading against arbitrary limits, here's a redesign of prompt_t to arrange that the buffer in which each prompt is stored can be reallocated larger during the input process. [originally from svn r9317]
2011-10-02 11:50:45 +00:00
break;
}
Use strbuf to store results in prompts_t. UBsan pointed out another memcpy from NULL (again with length 0) in the prompts_t system. When I looked at it, I realised that firstly prompt_ensure_result_size was an early not-so-good implementation of sgrowarray_nm that would benefit from being replaced with a call to the real one, and secondly, the whole system for storing prompt results should really have been replaced with strbufs with the no-move option, because that's doing all the same jobs better. So, now each prompt_t holds a strbuf in place of its previous manually managed string. prompt_ensure_result_size is gone (the console prompt-reading functions use strbuf_append, and everything else just adds to the strbuf in the usual marshal.c way). New functions exist to retrieve a prompt_t's result, either by reference or copied.
2020-01-21 20:19:47 +00:00
strbuf_shrink_to(pr->result, prev_result_len + ret);
Introduce and use strbuf_chomp. Those chomp operations in wincons.c and uxcons.c looked ugly, and I'm not totally convinced they couldn't underrun the buffer by 1 byte in weird circumstances. strbuf_chomp is neater.
2020-01-22 22:24:41 +00:00
if (strbuf_chomp(pr->result, '\n')) {
strbuf_chomp(pr->result, '\r');
While I'm crusading against arbitrary limits, here's a redesign of prompt_t to arrange that the buffer in which each prompt is stored can be reallocated larger during the input process. [originally from svn r9317]
2011-10-02 11:50:45 +00:00
break;
}
}
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SetConsoleMode(hin, savemode);
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!pr->echo)
Move sanitisation of k-i prompts into the SSH code. Now, instead of each seat's prompt-handling function doing the control-char sanitisation of prompt text, the SSH code does it. This means we can do it differently depending on the prompt. In particular, prompts _we_ generate (e.g. a genuine request for your private key's passphrase) are not sanitised; but prompts coming from the server (in keyboard-interactive mode, or its more restricted SSH-1 analogues, TIS and CryptoCard) are not only sanitised but also line-length limited and surrounded by uncounterfeitable headers, like I've just done to the authentication banners. This should mean that if a malicious server tries to fake the local passphrase prompt (perhaps because it's somehow already got a copy of your _encrypted_ private key), you can tell the difference.
2019-03-09 15:51:38 +00:00
console_write(hout, PTRLEN_LITERAL("\r\n"));
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
Use strbuf to store results in prompts_t. UBsan pointed out another memcpy from NULL (again with length 0) in the prompts_t system. When I looked at it, I realised that firstly prompt_ensure_result_size was an early not-so-good implementation of sgrowarray_nm that would benefit from being replaced with a call to the real one, and secondly, the whole system for storing prompt results should really have been replaced with strbufs with the no-move option, because that's doing all the same jobs better. So, now each prompt_t holds a strbuf in place of its previous manually managed string. prompt_ensure_result_size is gone (the console prompt-reading functions use strbuf_append, and everything else just adds to the strbuf in the usual marshal.c way). New functions exist to retrieve a prompt_t's result, either by reference or copied.
2020-01-21 20:19:47 +00:00
if (failed) {
While I'm crusading against arbitrary limits, here's a redesign of prompt_t to arrange that the buffer in which each prompt is stored can be reallocated larger during the input process. [originally from svn r9317]
2011-10-02 11:50:45 +00:00
return 0; /* failure due to read error */
}
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
}
Revamp SSH authentication code so that user interaction is more abstracted out; replace loops structured around a single interaction per loop with less tortuous code (fixes: `ki-multiprompt-crash', `ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and `proxy-password-prompt' easier). The new interaction abstraction has a lot of fields that are unused in the current code (things like window captions); this is groundwork for `gui-auth'. However, ssh.c still writes directly to stderr; that may want to be fixed. In the GUI apps, user interaction is moved to terminal.c. This should make it easier to fix things like UTF-8 username entry, although I haven't attempted to do so. Also, control character filtering can be tailored to be appropriate for individual front-ends; so far I don't promise anything other than not having made it any worse. I've tried to test this fairly exhaustively (although Mac stuff is untested, as usual). It all seems to basically work, but I bet there are new bugs. (One I know about is that you can no longer make the PuTTY window go away with a ^D at the password prompt; this should be fixed.) [originally from svn r6437] [this svn revision also touched putty-wishlist]
2005-10-30 20:24:09 +00:00
return 1; /* success */
Create the long-awaited console.c, and move the common routines out of scp.c, psftp.c and plink.c into it. Additionally, add `batch mode', in which all the interactive prompts (bad host key, log file exists, insecure cipher, password prompt) are disabled and safe responses are assumed. (The idea being that if you run PSCP, for example, in a cron job then you'd probably rather it failed and exited instead of leaving the cron job wedged while it waits for user input that will never arrive.) [originally from svn r1525]
2001-12-31 16:15:19 +00:00
}
Reference in New Issue Copy Permalink