The various setup routines can only receive CHANNEL_SUCCESS or
CHANNEL_FAILURE, so there's no need for the to worry about receiving
anything else. Strange packets will end up in do_ssh2_authconn
instead.
[originally from svn r9619]
In each case, want_reply was being treated as true even when it wasn't,
because it got decoded into "yes"/"no", both of which are true in
Perl.
[originally from svn r9617]
Each of the minor start-of-session requests is now dealt with by its own
little co-routine, while the shell/command is done in do_ssh2_authconn()
itself. This eliminates one more round-trip in session setup: PuTTY gets
all the way up to sending a shell request before worrying about any
replies.
[originally from svn r9616]
Now each channel has a queue of arbitrary handlers for those messages,
with anything that sends a CHANNEL_REQUEST with want_reply true pushing
a new entry onto the queue, and a shared handler that dispatches
responses appropriately.
Currently, this is only used for winadj@putty.projects.tartarus.org, but
extending it to cover the initial requests as well shouldn't be too
painful.
[originally from svn r9615]
There's no need to have identical code generating server-to-client and
client-to-server versions of the cipher and MAC lists; a couple of
twice-around loops will do fine.
[originally from svn r9610]
Before, NULL in the dispatch table meant "send to the appropriate one of
do_ssh2_transport() and do_ssh2_authconn()". Now those (via small
shims) are specified directly in the dispatch table, so ssh2_protocol()
is much simpler.
In the process, this has somewhat centralised the handling of gross
server protocol violations. PuTTY will now disconnect with a rude
message when (e.g.) OpenSSH sends us an SSH_MSG_UNIMPLEMENTED when we
try to KEXINIT during authentication.
[originally from svn r9609]
using one for the length field and one for the rest of the packet
contents. Since sftp_senddata() has no queuing or deferral mechanism
but instead constructs and sends an SSH2_MSG_CHANNEL_DATA message
immediately, this change has the effect of ceasing to split every SFTP
packet across two SSH messages.
[originally from svn r9603]
bufchain_add() now allocates at most one new granule. Granules still
have a minimum size, so small adds still get coalesced.
The main practical consequence of this is that PSCP and PSFTP now
generate 4K SSH packets rather than 512-byte ones. Also, the compiled
code (on my Ubuntu box) is fractionally smaller.
[originally from svn r9602]
by sending most of the initial SSH_MSG_CHANNEL_REQUEST messages before
waiting for any replies. The initial version of this code was a clever
thing with a two-pass loop, but that got hairy so I went for the simpler
approach of separating the request and reply code and having flags to
keep track of which requests have been sent.
[originally from svn r9599]
winadj@putty.projects.tartarus.org request. Not currently enabled
automatically, but should be usable as a manual workaround.
[originally from svn r9592]
zero but does it in such a way that over-clever compilers hopefully
won't helpfully optimise the call away if you do it just before
freeing something or letting it go out of scope. Use this for
(hopefully) every memset whose job is to destroy sensitive data that
might otherwise be left lying around in the process's memory.
[originally from svn r9586]
having just noticed that Makefile.gtk had it and this one doesn't. (Of
course, this being autoconf, we can easily enough make it conditional
on the compiler actually being gcc.)
[originally from svn r9583]
compile warning ('left-hand operand of comma expression has no
effect'), which of course becomes fatal under -Werror.
(This would have been instantly noticeable to people compiling with
the old-fashioned Makefile.gtk, which does include -Wall -Werror, but
those of us using the new autoconf makefile hadn't noticed.)
[originally from svn r9582]
platform manner, but which nothing ever called. It thus served only to
trap up the unwary. The live function key handling code lives in the
frontends, i.e. window.c on Windows and gtkwin.c on Unix.
[originally from svn r9579]
and the argument list contains only one string, try again by passing
that single string to "$SHELL -c" to be parsed as a shell command.
This matches xterm's behaviour (as of xterm 261, at least), and means
in practice that users can do _either_ of 'pterm -e some command' and
'pterm -e "some command"'.
(A quick survey suggests that the majority of X terminal programs agree
with pterm's old behaviour of only supporting '-e some command',
except that gnome-terminal only supports the other behaviour and xterm
supports both. With that disagreement, I think supporting both is
probably the sensible thing.)
[originally from svn r9575]
piece of keyboard handling: if Num Lock is on, numeric keypad keys are
eaten by the IM, so we must avoid passing them to the IM in the first
place if we're in any non-default numeric keypad mode (application or
Nethack).
This is a grubby way to do it, but the more obvious approach of just
moving the Nethack and app-keypad if statements up to above the IM
call doesn't work because those statements depend on the generic
Alt-prefix handling that happens just _below_ the IM call. So instead
I just repeat the list of keystrokes and modes in an if statement
conditionalising the IM call.
[originally from svn r9573]
[r9567 == 7fc8db15b2]
FXP_READDIR on an empty directory by returning a zero-length list of
filenames, instead of the more common response of a list containing
just "." and "..". Stop PSFTP failing an assertion when that happens.
[originally from svn r9569]
a GtkIMMulticontext and having that filter most keypresses. I think
I've got this right so that it doesn't break any previous deliberate
keyboard-handling behaviour that's now _after_ the 'if (filter
keypress) return' statement.
[originally from svn r9567]
unconditionally set the telnet state to SEENCR regardless of whether
we have actually seen a CR, and as a result sending a NUL through
PuTTY (via Ctrl-Space or whatever) does not work. Must have arisen
through some kind of really weird cut-and-paste error!
[originally from svn r9545]
The previous platform-dependent ifdefs, switching between a system
which tried to cope with spurious callbacks (which I'd observed on
Windows) and one which tried to cope with system clock jumps (which
can happen on Unix, if you use gettimeofday) have been completely
removed, and replaced with a much simpler approach which just copes
with system clock jumps by triggering any timers immediately.
None of the resulting effects should be catastrophic (the worst thing
might be the waste of CPU in a spurious rekey, but as long as the
system clock isn't jumping around _all_ the time that's hardly
critical) and in any case the Unix port has had a long-standing oddity
involving occasional lockups if pterm or PuTTY runs for too long,
which hopefully this should replace with a much less bad failure mode.
And the code is much simpler, which is not to be sneezed at.
[originally from svn r9528]
sequence: since init_fonts sets up ucsdata based on the available
Windows fonts, we should call it before passing ucsdata to term_init.
[originally from svn r9527]
calling back->unthrottle), we should immediately call
ssh_process_queued_incoming_data to handle the SSH packets that have
been saved for later functioning while we were throttled. Otherwise,
they'll sit there unhandled until the next call to ssh_gotdata, which
might not be for ages if the server thinks it's waiting for us.
[originally from svn r9523]
forwarded X connection. (I somehow forgot to do this in r9364, despite
making the identical change in portfwd.c.)
[originally from svn r9470]
[r9364 == 49927f6c4d]
the offset horizontal line characters in the VT100 line-drawing set
(o,p,r,s), so that no trace of it - and hence no pointless performance
hit - is compiled into the cross-platform modules on non-Windows
platforms.
[originally from svn r9467]
will not even initialise sbstring[0], so we shouldn't even look at it
let alone depend on it to tell us the desired character was absent.
[originally from svn r9465]
logevent(), which temporarily turn off the raw mode we've put stderr
into, so that they don't get called if the log_eventlog() call between
them is not _actually_ going to write to stderr.
Fixes a bug in which, if you define a Unix PuTTY saved session which
uses 'plink -nc' as a local proxy command and then run PuTTY
backgrounded from the shell with that session loaded, the subprocess
Plink would get SIGTTOU when it tried to muck about with stderr and
the whole thing would grind to a halt. I'm prepared to consider that
acceptable if Plink _really_ wants to write on standard error, but if
it doesn't, it should just carry on working in the background!
[originally from svn r9462]
