which suggested bufchain_prefix() was finding an improperly
initialised bufchain structure. Looking at the code, this may indeed
have been able to happen, since the bufchain in a SOCKDATA_DORMANT
channel was not initialised until CHANNEL_OPEN_CONFIRMATION was
received. This seems utterly daft, so I now call bufchain_init()
when the channel structure is actually created. With any luck the
crash will mystically disappear now (I wasn't able to reproduce it
myself).
[originally from svn r1735]
inclusive. Padding is accomplished by rewriting the signature blob
rather than at the point of generation, in order to avoid having to
move part of the workaround into Pageant (and having to corrupt the
agent wire protocol to allow PuTTY to specify whether it wants its
signatures padded!).
[originally from svn r1708]
now be told that the key is the wrong type, _and_ what type it is,
rather than being given a blanket `unable to read key file' message.
[originally from svn r1662]
forwardings in SSH1. Was causing several MSG_SUCCESS to be queued up
unread, which was wrong-but-benign in most cases but caused a hard
crash with compression enabled (one of those uncompressed
MSG_SUCCESSes was fed to the zlib decompressor with spectacular
results).
[originally from svn r1609]
CONNECT, but contains an extensible framework to allow other
proxies. Apparently SOCKS and ad-hoc-telnet-proxy are already
planned (the GUI mentions them already even though they don't work
yet). GUI includes full configurability and allows definition of
exclusion zones. Rock and roll.
[originally from svn r1598]
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]
keys before _every_ other authentication; so if you tried a local
pubkey _and_ a password, for example, you'd also try Pageant twice.
Now fixed.
[originally from svn r1524]
the private key file given in the config; if it spots this then it
avoids trying it again (and in particular avoids needing to ask for
the passphrase when it knows perfectly well it won't work).
[originally from svn r1523]
process. This is functional in SSH, and vestigial (just returns 0)
in the other three protocols. Plink's Windows exit code is now
determined by the remote process exit code, which should make it
more usable in scripting applications. Tested in both SSH1 and SSH2.
[originally from svn r1518]
connections from outside localhost' switch. Interestingly OpenSSH
3.0 appears to ignore this (though I know it works because ssh.com
3.0 gets it right, and the SSH packet dump agrees that I'm doing the
right thing).
[originally from svn r1496]
sick of recompiling to enable packet dumps. SSH packet dumping is
now provided as a logging option, and dumps to putty.log like all
the other logging options. While I'm at it I cleaned up the format
so that packet types are translated into strings for easy browsing.
POSSIBLE SIDE EFFECT: in the course of this work I had to re-enable
the SSH1 packet length checks which it turns out hadn't actually
been active for some time, so it's possible things might break as a
result. If need be I can always disable those checks for the 0.52
release and think about it more carefully later.
[originally from svn r1493]
configurable option so users can re-enable the feature _if_ they
know they have an SSH2 server that isn't going to get shirty about
it. Inspired by a spectacular increase in OpenSSH's shirtiness.
[originally from svn r1474]
after. Shouldn't make a difference for any server that previously
worked, but we should now interoperate sensibly with servers that
wait to receive our NEWKEYS before sending their own. Apparently
Unisphere produce one such.
[originally from svn r1390]
causes password login to occur on a server that supports password-
through-k-i. Of course when we use the new preference list mechanism
for selecting the order of authentications this will all become much
more sane, but for the moment I've put publickey back up to the top
and things seem to be happier.
[originally from svn r1220]
CHANNEL_OPEN_FAILURE messages, which occur when the remote side is
unable to open a forwarded network connection we have requested. (It
seems they _don't_ show up if you get something mundane like
Connection Refused - the channel is cheerfully opened and
immediately slammed shut - but they do if you try to connect to a
host that doesn't even exist. Try forwarding a port to
frogwibbler:4800 and see what you get.)
[originally from svn r1213]
