now be processed in cmdline.c, which is called from all utilities
(well, not Pageant or PuTTYgen). This should mean we get to
standardise almost all options across almost all tools. Also one
major change: `-load' is now the preferred option for loading a
saved session in PuTTY proper. `@session' still works but is
deprecated.
[originally from svn r1799]
authentication: a k-i request packet can contain any number of auth
prompts (including zero!) and we must ask the user all of them and
send back a packet containing the same number of responses. FreeBSD
systems were sending a zero-prompts packet which was crashing us;
this now appears fixed (we correctly return a zero-responses packet)
but I haven't tested a multiple-prompts packet because I can't
immediately think of a server that generates them.
[originally from svn r1797]
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]
