ability to do synchronous ones as well, because PSCP and PSFTP don't
really need async ones and it would have been a serious pain to
implement them. Also, Pageant itself when run as a client of its
primary instance doesn't benefit noticeably from async agent
requests.
[originally from svn r3154]
malloc functions, which automatically cast to the same type they're
allocating the size of. Should prevent any future errors involving
mallocing the size of the wrong structure type, and will also make
life easier if we ever need to turn the PuTTY core code from real C
into C++-friendly C. I haven't touched the Mac frontend in this
checkin because I couldn't compile or test it.
[originally from svn r3014]
completely from putty.h. It's now static in each of the command-line
front ends, shared only between window.c and windlg.c in PuTTY
proper (I've tested this by doing #define cfg cfgsillyname in those
two files only, and it still links so nobody else is using that
symbol!), and part of the `inst' structure in pterm. I think that
only leaves the Unicode module as the last stubborn holdout in the
anti-global-variables campaign.
[originally from svn r2568]
and have a function to pass in a new one. (Well, actually several
back ends don't actually bother to do this because they need nothing
out of Config after the initial setup phase, but they could if they
wanted to.)
[originally from svn r2561]
absent, and also (I think) all the frontend request functions (such
as request_resize) take a context pointer, so that multiple windows
can be handled sensibly. I wouldn't swear to this, but I _think_
that only leaves the Unicode stuff as the last stubborn holdout.
[originally from svn r2147]
As a result I've now been able to turn the global variables `back'
and `backhandle' into module-level statics in the individual front
ends. Now _that's_ progress!
[originally from svn r2142]
each backend now stores all its internal variables in a big struct,
and each backend function gets a pointer to this struct passed to
it. This still isn't the end of the work - lots of subsidiary things
still use globals, notably all the cipher and compressor modules and
the X11 forwarding authentication stuff. But ssh.c itself has now
been transformed, and that was the really painful bit, so from here
on it all ought to be a sequence of much smaller and simpler pieces
of work.
[originally from svn r2127]
all the global and function-static variables out of terminal.c into
a dynamically allocated data structure. Note that this does not yet
confer the ability to run more than one of them in the same process,
because other things (the line discipline, the back end) are still
global, and also in particular the address of the dynamically
allocated terminal-data structure is held in a global variable
`term'. But what I've got here represents a reasonable stopping
point at which to check things in. In _theory_ this should all still
work happily, on both Unix and Windows. In practice, who knows?
[originally from svn r2115]
The current pty.c backend is temporarily a loopback device for
terminal emulator testing, the display handling is only just enough
to show that terminal.c is functioning, the keyboard handling is
laughable, and most features are absent. Next step: bring output and
input up to a plausibly working state, and put a real pty on the
back to create a vaguely usable prototype. Oh, and a scrollbar would
be nice too.
In _theory_ the Windows builds should still work fine after this...
[originally from svn r2010]
Updated manual to reflect reality (e.g. usage messages, '-p port' not actually
implemented, sprinkle references to '-i keyfile').
(I've put "Release 0.53" in the messages; let's hope this doesn't cause a
flood of "where is 0.53?" email.)
I don't guarantee that the result is entirely sane and sensible in all
respects, but it is at least consistent.
[originally from svn r1951]
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]
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]
mode ever failed to do this, and only Plink actually had a problem
with it, so this didn't become obvious for a while. rlogin mode is
fixed, and all implementations of from_backend() now contain an
assertion so that we should spot errors of this type more quickly in
future.
[originally from svn r1571]
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]
