simon-git: putty (main): Simon Tatham
Commits to Tartarus hosted VCS
tartarus-commits at lists.tartarus.org
Sat Nov 26 10:52:24 GMT 2022
TL;DR:
819efc3c Support horizontal scroll events in mouse tracking.
1625fd8f Handle the -batch option centrally in cmdline.c.
dbd0bde4 New utility function burnwcs().
f91c3127 split_into_argv: add special case for program name.
80aed962 New system for reading prompts from the console.
f4519b65 Add UTF-8 support to the new Windows ConsoleIO system.
Repository: https://git.tartarus.org/simon/putty.git
On the web: https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer: Simon Tatham <anakin at pobox.com>
Date: 2022-11-26 10:52:24
commit 819efc3c2150ed70c9e5f3a0abad777043e159d0
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=819efc3c2150ed70c9e5f3a0abad777043e159d0;hp=5f2eff2fea10642a445c90d377d816fa5cace3d4
Author: Simon Tatham <anakin at pobox.com>
Date: Tue Nov 22 18:36:23 2022 +0000
Support horizontal scroll events in mouse tracking.
Horizontal scroll events aren't generated by the traditional mouse
wheel, but they can be generated by trackpad gestures, though this
isn't always configured on.
The cross-platform and Windows parts of this patch is due to
Christopher Plewright; I added the GTK support.
putty.h | 3 ++-
terminal/terminal.c | 8 ++++++++
unix/window.c | 50 ++++++++++++++++++++++++++++++++++++++++----------
windows/window.c | 14 +++++++++-----
4 files changed, 59 insertions(+), 16 deletions(-)
commit 1625fd8fcbed72edf13ca626a319654e549145b3
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=1625fd8fcbed72edf13ca626a319654e549145b3;hp=819efc3c2150ed70c9e5f3a0abad777043e159d0
Author: Simon Tatham <anakin at pobox.com>
Date: Thu Nov 24 20:00:48 2022 +0000
Handle the -batch option centrally in cmdline.c.
This removes one case from several of the individual tools'
command-line parsers, and moves it into a central place where it will
automatically be supported by any tool containing console.c.
In order to make that not cause a link failure, there's now a
stubs/no-console.c which GUI clients of cmdline.c must include.
cmdline.c | 16 +++++++++++++++-
console.c | 6 ++++++
pscp.c | 2 --
psftp.c | 2 --
putty.h | 2 ++
stubs/no-console.c | 10 ++++++++++
unix/CMakeLists.txt | 9 +++++++--
unix/plink.c | 2 --
windows/CMakeLists.txt | 3 +++
windows/plink.c | 2 --
10 files changed, 43 insertions(+), 11 deletions(-)
commit dbd0bde41563bc6c29862a1e475b085ec0c66557
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=dbd0bde41563bc6c29862a1e475b085ec0c66557;hp=1625fd8fcbed72edf13ca626a319654e549145b3
Author: Simon Tatham <anakin at pobox.com>
Date: Thu Nov 24 12:30:18 2022 +0000
New utility function burnwcs().
Just like burnstr(), it memsets a NUL-terminated string to all zeroes
before freeing it. The only difference is that it does it to a string
of wchar_t.
misc.h | 1 +
utils/CMakeLists.txt | 1 +
utils/burnwcs.c | 18 ++++++++++++++++++
3 files changed, 20 insertions(+)
commit f91c3127ad241ac2a4a292aec993fb25adbe86a7
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=f91c3127ad241ac2a4a292aec993fb25adbe86a7;hp=dbd0bde41563bc6c29862a1e475b085ec0c66557
Author: Simon Tatham <anakin at pobox.com>
Date: Thu Nov 24 12:54:19 2022 +0000
split_into_argv: add special case for program name.
In the Windows API, there are two places you can get a command line in
the form of a single unsplit string. One is via the command-line
parameter to WinMain(); the other is by calling GetCommandLine(). But
the two have different semantics: the WinMain command line string is
only the part after the program name, whereas GetCommandLine() returns
the full command line _including_ the program name.
PuTTY has never yet had to parse the full output of GetCommandLine,
but I have plans that will involve it beginning to do so. So I need to
make sure the utility function split_into_argv() can handle it.
This is not trivial because the quoting convention is different for
the program name than for everything else. In the program's normal
arguments, parsed by the C library startup code, the convention is
that backslashes are special when they appear before a double quote,
because that's how you write a literal double quote. But in the
program name, backslashes are _never_ special, because that's how
CreateProcess parses the program name at the start of the command
line, and the C library must follow suit in order to correctly
identify where the program name ends and the arguments begin.
In particular, consider a command line such as this:
"C:\Program Files\Foo\"foo.exe "hello \"world\""
The \" in the middle of the program name must be treated as a literal
backslash, followed by a non-literal double quote which matches the
one at the start of the string and causes the space in 'Program Files'
to be treated as part of the pathname. But the same \" when it appears
in the subsequent argument is treated as an escaped double quote, and
turns into a literal " in the argument string.
This commit adds support for this special initial-word handling in
split_into_argv(), via an extra boolean argument indicating whether to
turn that mode on. However, all existing call sites set the flag to
false, because the new mode isn't needed _yet_. So there should be no
functional change.
windows/pageant.c | 2 +-
windows/platform.h | 3 ++-
windows/pterm.c | 2 +-
windows/putty.c | 2 +-
windows/puttygen.c | 2 +-
windows/utils/split_into_argv.c | 47 +++++++++++++++++++++++++++++++++++++----
6 files changed, 49 insertions(+), 9 deletions(-)
commit 80aed962862ec73e231cb0c0bfd7d94dbc4d4bc3
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=80aed962862ec73e231cb0c0bfd7d94dbc4d4bc3;hp=f91c3127ad241ac2a4a292aec993fb25adbe86a7
Author: Simon Tatham <anakin at pobox.com>
Date: Thu Nov 24 12:46:25 2022 +0000
New system for reading prompts from the console.
Until now, the command-line PuTTY tools (PSCP, PSFTP and Plink) have
presented all the kinds of interactive prompt (password/passphrase,
host key, the assorted weak-crypto warnings, 'append to log file?') on
standard error, and read the responses from standard input.
This is unfortunate because if you're redirecting their standard
input (especially likely with Plink) then the prompt responses will
consume some of the intended session data. It would be better to
present the prompts _on the console_, even if that's not where stdin
or stderr point.
On Unix, we've been doing this for ages, by opening /dev/tty directly.
On Windows, we didn't, because I didn't know how. But I've recently
found out: you can open the magic file names CONIN$ and CONOUT$, which
will point at your actual console, if one is available.
So now, if it's possible, the command-line tools will do that. But if
the attempt to open CONIN$ and CONOUT$ fails, they'll fall back to the
old behaviour (in particular, if no console is available at all).
In order to make this happen consistently across all the prompt types,
I've introduced a new object called ConsoleIO, which holds whatever
file handles are necessary, knows whether to close them
afterwards (yes if they were obtained by opening CONFOO$, no if
they're the standard I/O handles), and presents a BinarySink API to
write to them and a custom API to read a line of text.
This seems likely to break _someone's_ workflow. So I've added an
option '-legacy-stdio-prompts' to restore the old behaviour.
cmdline.c | 10 ++
putty.h | 1 +
stubs/no-console.c | 5 +
unix/console.c | 8 +
windows/console.c | 501 +++++++++++++++++++++++++++++++++--------------------
5 files changed, 337 insertions(+), 188 deletions(-)
commit f4519b6533b089ddb8df26d9f9fddb94dd1f3dee
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=f4519b6533b089ddb8df26d9f9fddb94dd1f3dee;hp=80aed962862ec73e231cb0c0bfd7d94dbc4d4bc3
Author: Simon Tatham <anakin at pobox.com>
Date: Fri Nov 25 12:57:43 2022 +0000
Add UTF-8 support to the new Windows ConsoleIO system.
This allows you to set a flag in conio_setup() which causes the
returned ConsoleIO object to interpret all its output as UTF-8, by
translating it to UTF-16 and using WriteConsoleW to write it in
Unicode. Similarly, input is read using ReadConsoleW and decoded from
UTF-16 to UTF-8.
This flag is set to false in most places, to avoid making sudden
breaking changes. But when we're about to present a prompts_t to the
user, it's set from the new 'utf8' flag in that prompt, which in turn
is set by the userauth layer in any case where the prompts are going
to the server.
The idea is that this should be the start of a fix for the long-
standing character-set handling bug that strings transmitted during
SSH userauth (usernames, passwords, k-i prompts and responses) are all
supposed to be in UTF-8, but we've always encoded them in whatever our
input system happens to be using, and not done any tidying up on them.
We get occasional complaints about this from users whose passwords
contain characters that are encoded differently between UTF-8 and
their local encoding, but I've never got round to fixing it because
it's a large piece of engineering.
Indeed, this isn't nearly the end of it. The next step is to add UTF-8
support to all the _other_ ways of presenting a prompts_t, as best we
can.
Like the previous change to console handling, it seems very likely
that this will break someone's workflow. So there's a fallback
command-line option '-legacy-charset-handling' to revert to PuTTY's
previous behaviour.
cmdline.c | 10 ++++
misc.h | 7 +--
putty.h | 12 +++++
ssh/userauth2-client.c | 4 ++
stubs/no-console.c | 5 ++
unix/console.c | 6 +++
utils/dup_mb_to_wc.c | 21 +++++---
utils/dup_wc_to_mb.c | 18 ++++---
utils/prompts.c | 1 +
windows/console.c | 137 +++++++++++++++++++++++++++++++++++++++++--------
10 files changed, 184 insertions(+), 37 deletions(-)
More information about the tartarus-commits
mailing list