of scp.c, psftp.c and plink.c into it. Additionally, add `batch
mode', in which all the interactive prompts (bad host key, log file
exists, insecure cipher, password prompt) are disabled and safe
responses are assumed. (The idea being that if you run PSCP, for
example, in a cron job then you'd probably rather it failed and
exited instead of leaving the cron job wedged while it waits for
user input that will never arrive.)
[originally from svn r1525]
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]
now a passphrase-keyed MAC covering _all_ important data in the
file, including the public blob and the key comment. Should
conclusively scupper any attacks based on nobbling the key file in
an attempt to sucker the machine that decrypts it. MACing the
comment field also protects against a key-substitution attack (if
someone's worked out a way past our DSA protections and can extract
the private key from a signature, swapping key files and
substituting comments might just enable them to get the signature
they need to do this. Paranoid, but might as well).
[originally from svn r1413]
term_out() can in turn call ldisc_send() which calls back to
from_backend() when local echo is enabled. This was giving rise to
crazy re-entrancy stuff and stack overflows. Instead from_backend()
deposits its data in a bufchain which term_out() empties the next
time it's called.
[originally from svn r1276]
Partly because that's a good idea _anyway_, and partly because it
seems to be causing trouble. (Specifically, their pathetic attempt
to emulate plink's proper select handling seems to get confused when
the back end tries to open a local listening socket.)
[originally from svn r1264]
compute (100*a)/b. Instead compute 100*(a/b), because that way
there's no chance that 100*a will become inexact enough to fail to
yield 100 when a==b.)
[originally from svn r1254]
_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]
_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]
host-key-changed prompt: update-cache-and-connect, connect-without-
updating-cache, and abandon-connection. (Previously the middle one
was missing.)
[originally from svn r1122]
the server. (Not sure _why_ they're sent to the server; scp is
weird.) It may be pointless when sent to the screen, which is why I
removed it, but it's extremely pointful on the wire :-(
[originally from svn r1090]
multiple switchable line disciplines, we now have a single unified
one which changes its behaviour based on option settings. Each
option setting can be suggested by the back end and/or the terminal
handler, and can be forcibly overridden by the configuration. Local
echo and local line editing are separate, independently switchable,
options.
[originally from svn r895]
smalloc() macros and thence to the safemalloc() functions in misc.c.
This should allow me to plug in a debugging allocator and track
memory leaks and segfaults and things.
[originally from svn r818]
advantages:
- protocol modules can call sk_write() without having to worry
about writes blocking, because blocking writes are handled in the
abstraction layer and retried later.
- `Lost connection while sending' is a thing of the past.
- <winsock.h> is no longer needed in most modules, because
"putty.h" doesn't have to declare `SOCKET' variables any more,
only the abstracted `Socket' type.
- select()-equivalent between multiple sockets will now be handled
sensibly, which opens the way for things like SSH port
forwarding.
[originally from svn r744]
thought. As well as the ".." attack in recursive copies, the name
sent by the client was also trusted in a single-file implicit-
destination copy such as "pscp host:foo .". (The result was ./foo,
where foo is what the server claimed the file was rather than what
the user asked for. I think it's not unreasonable that if the user
requests file `foo' from the host, he should get the result in a
file called `foo' no matter what the host thinks.)
[originally from svn r743]
