_think_ there was an exploit (even if the server sends "c:foobar",
the client will not attempt to create "c:foobar"; instead it will
try to create ".\c:foobar" which will fail), but it's as well to be
sure.
[originally from svn r1223]
construction. Doesn't actually affect anything right now, since the
bug was a failure to round a length up to the next multiple of 4 and
it so happens that our current message was exactly 40 bytes anyway
:-) But if we start giving a wider variety of messages one day then
it might be handy to be able to do them without gratuitous crashes.
[originally from svn r1222]
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]
code _ever_ worked before! But it's been like this for four months
and nobody has noticed, including me. That's quite spooky.
[originally from svn r1219]
(as well as showing it for cut and paste). For SSH1, this feature is
largely cosmetic and added for orthogonality; it comes into its own
in SSH2, where it saves the Official One True Public Key Format as
specified in the draft spec, and more particularly as used by
ssh.com's product for authentication. Now that ssh-3.0.1 supports
RSA user keys, this is suddenly actually useful.
[originally from svn r1217]
done properly (by binding to INADDR_LOOPBACK) instead of hackishly
(by binding to INADDR_ANY, looking at the peer address when a
connection is accepted, and slamming the connection shut at that
point).
[originally from svn r1215]
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]
_right_ way. (SSWs are disabled by default and can be re-enabled
using `-unsafe', meaning that pscp will _never_ do anything
unexpected to your local file system unless you explicitly give
consent. The sftp-based variant will work fine because the
corresponding mechanism is _not_ unsafe.)
[originally from svn r1212]
scp1 if it can't. Currently not very tested - I checked it in as
soon as it completed a successful recursive copy in both directions.
Also, one known bug: you can't specify a remote wildcard, because by
the nature of SFTP we'll need to implement the wildcard engine on
the client side. I do intend to do this (and use the same wildcard
engine in PSFTP as well) but I haven't got round to it yet.
[originally from svn r1208]
actually get things done. I'm sure this is the second time I've
checked in this mistake :-/ Still, this time I've got right to the
bottom of the cause, and commented it clearly. Phew.
[originally from svn r1207]
malicious SCP server could have written to areas other than the ones
the user requested; cleared up buffer overruns everywhere. Hopefully
we now do not use arbitrary buffer limits _anywhere_.
[originally from svn r1205]
by me to make the drag list behaviour slightly more intuitive.
WARNING: DO NOT LOOK AT pl_itemfrompt() IF YOU ARE SQUEAMISH.
[originally from svn r1199]
by ceasing to listen on input channels if the corresponding output
channel isn't accepting data. Has had basic check-I-didn't-actually-
break-anything-too-badly testing, but hasn't been genuinely tested
in stress conditions (because concocting stress conditions is non-
trivial).
[originally from svn r1198]
keyboard-interactive authentication. UNTESTED except that I checked
it compiles. Will ask for testing from the user who complained.
[originally from svn r1195]
box. Also default to ISO8859-1 so that CSI works in the default
mode; this is ridiculously Western-centric but I can't honestly
think of a better option.
[originally from svn r1183]
attempt keyboard-interactive authentication. We can yell about it if
we make a creditable attempt and are rejected, but if the server
just refuses to even consider it then the user won't really want to
know (and if they do there's the Event Log).
[originally from svn r1180]
Only currently works on SSH1; SSH2 should be doable but it's late
and I have other things to do tonight. The Cool Guy award for this
one goes to Nicolas Barry, for doing most of the work and actually
understanding the code he was adding to.
[originally from svn r1176]
