We define a macro in terms of INT_MAX, so we ought to include
<limits.h> to ensure INT_MAX is defined, rather than depending on
every call site to have remembered to do that themselves.
In order to list cross-certifiable host keys in the GUI specials menu,
the SSH backend has been inventing new values on the end of the
Telnet_Special enumeration, starting from the value TS_LOCALSTART.
This is inelegant, and also makes it awkward to break up special
handlers (e.g. to dispatch different specials to different SSH
layers), since if all you know about a special is that it's somewhere
in the TS_LOCALSTART+n space, you can't tell what _general kind_ of
thing it is. Also, if I ever need another open-ended set of specials
in future, I'll have to remember which TS_LOCALSTART+n codes are in
which set.
So here's a revamp that causes every special to take an extra integer
argument. For all previously numbered specials, this argument is
passed as zero and ignored, but there's a new main special code for
SSH host key cross-certification, in which the integer argument is an
index into the backend's list of available keys. TS_LOCALSTART is now
a thing of the past: if I need any other open-ended sets of specials
in future, I can add a new top-level code with a nicely separated
space of arguments.
While I'm at it, I've removed the legacy misnomer 'Telnet_Special'
from the code completely; the enum is now SessionSpecialCode, the
struct containing full details of a menu entry is SessionSpecial, and
the enum values now start SS_ rather than TS_.
Originally, it controlled whether ssh.c should send terminal messages
(such as login and password prompts) to terminal.c or to stderr. But
we've had the from_backend() abstraction for ages now, which even has
an existing flag to indicate that the data is stderr rather than
stdout data; applications which set FLAG_STDERR are precisely those
that link against uxcons or wincons, so from_backend will do the
expected thing anyway with data sent to it with that flag set. So
there's no reason ssh.c can't just unconditionally pass everything
through that, and remove the special case.
FLAG_STDERR was also used by winproxy and uxproxy to decide whether to
capture standard error from a local proxy command, or whether to let
the proxy command send its diagnostics directly to the usual standard
error. On reflection, I think it's better to unconditionally capture
the proxy's stderr, for three reasons. Firstly, it means proxy
diagnostics are prefixed with 'proxy:' so that you can tell them apart
from any other stderr spew (which used to be particularly confusing if
both the main application and the proxy command were instances of
Plink); secondly, proxy diagnostics are now reliably copied to packet
log files along with all the other Event Log entries, even by
command-line tools; and thirdly, this means the option to suppress
proxy command diagnostics after the main session starts will actually
_work_ in the command-line tools, which it previously couldn't.
A more minor structure change is that copying of Event Log messages to
stderr in verbose mode is now done by wincons/uxcons, instead of
centrally in logging.c (since logging.c can now no longer check
FLAG_STDERR to decide whether to do it). The total amount of code to
do this is considerably smaller than the defensive-sounding comment in
logevent.c explaining why I did it the other way instead :-)
Now there's a centralised routine in misc.c to do the sanitisation,
which copies data on to an outgoing bufchain. This allows me to remove
from_backend_untrusted() completely from the frontend API, simplifying
code in several places.
Two use cases for untrusted-terminal-data sanitisation were in the
terminal.c prompts handler, and in the collection of SSH-2 userauth
banners. Both of those were writing output to a bufchain anyway, so
it was very convenient to just replace a bufchain_add with
sanitise_term_data and then not have to worry about it again.
There was also a simplistic sanitiser in uxcons.c, which I've now
replaced with a call to the good one - and in wincons.c there was a
FIXME saying I ought to get round to that, which now I have!
Most of these were 'void *' because they weren't even reliably a
structure type underneath - the per-OS storage systems would directly
cast read/write/enum settings handles to and from random things like
FILE *, Unix DIR *, or Windows HKEY. So I've wrapped them in tiny
structs for the sake of having a sensible structure tag visible
elsewhere in the code.
This is another major source of unexplained 'void *' parameters
throughout the code.
In particular, the currently unused testback.c actually gave the wrong
pointer type to its internal store of the frontend handle - it cast
the input void * to a Terminal *, from which it got implicitly cast
back again when calling from_backend, and nobody noticed. Now it uses
the right type internally as well as externally.
Nearly every part of the code that ever handles a full backend
structure has historically done it using a pair of pointer variables,
one pointing at a constant struct full of function pointers, and the
other pointing to a 'void *' state object that's passed to each of
those.
While I'm modernising the rest of the code, this seems like a good
time to turn that into the same more or less type-safe and less
cumbersome system as I'm using for other parts of the code, such as
Socket, Plug, BinaryPacketProtocol and so forth: the Backend structure
contains a vtable pointer, and a system of macro wrappers handles
dispatching through that vtable.
Same principle again - the more of these structures have globally
visible tags (even if the structure contents are still opaque in most
places), the fewer of them I can mistake for each other.
That's one fewer anonymous 'void *' which might be accidentally
confused with some other pointer type if I misremember the order of
function arguments.
While I'm here, I've made its pointer-nature explicit - that is,
'Ldisc' is now a typedef for the structure type itself rather than a
pointer to it. A stylistic change only, but it feels more natural to
me these days for a thing you're going to eventually pass to a 'free'
function.
This commit adds the new ids and fingerprints in the keys appendix of
the manual, and moves the old ones down into the historic-keys
section. I've tweaked a few pieces of wording for ongoing use, so that
they don't imply a specific number of past key rollovers.
The -pgpfp option in all the tools now shows the new Master Key
fingerprint and the previous (2015) one. I've adjusted all the uses of
the #defines in putty.h so that future rollovers should only have to
modify the #defines themselves.
Most importantly, sign.sh bakes in the ids of the current release and
snapshot keys, so that snapshots will automatically be signed with the
new snapshot key and the -r option will invoke the new release key.
Like the corresponding rewrite of conf serialisation, this affects not
just conf_deserialise itself but also the per-platform filename and
fontspec deserialisers.
This is a cleanup I started to notice a need for during the BinarySink
work. It removes a lot of faffing about casting things to char * or
unsigned char * so that some API will accept them, even though lots of
such APIs really take a plain 'block of raw binary data' argument and
don't care what C thinks the signedness of that data might be - they
may well reinterpret it back and forth internally.
So I've tried to arrange for all the function call APIs that ought to
have a void * (or const void *) to have one, and those that need to do
pointer arithmetic on the parameter internally can cast it back at the
top of the function. That saves endless ad-hoc casts at the call
sites.
There was a time, back when the USA was more vigorously against
cryptography, when we toyed with the idea of having a version of PuTTY
that outsourced its cryptographic primitives to the Microsoft optional
encryption API, which would effectively create a tool that acted like
PuTTY proper on a system with that API installed, but automatically
degraded to being PuTTYtel on a system without, and meanwhile (so went
the theory) it could be moved freely across national borders with
crypto restrictions, because it didn't _contain_ any of the actual
crypto.
I don't recall that we ever got it working at all. And certainly the
vestiges of it here and there in the current code are completely
unworkable - they refer to an 'mscrypto.c' that doesn't even exist,
and the ifdefs in the definitions of structures like RSAKey and
MD5Context are not matched by any corresponding ifdefs in the code. So
I ought to have got round to removing it long ago, in order to avoid
misleading anyone.
This simplifies the client code both in ssh.c and in the client side
of Pageant.
I've cheated a tiny bit by preparing agent requests in a strbuf that
has space reserved at the front for the packet frame, which makes life
easier for the code that sends them off.
Now instead of iterating through conf twice in separate functions,
once to count up the size of the serialised data and once to write it
out, I just go through once and dump it all in a strbuf.
(Of course, I could still do a two-pass count-then-allocate approach
easily enough in this system; nothing would stop me writing a
BinarySink implementation that didn't actually store any data and just
counted its size, and then I could choose at each call site whether I
preferred to do it that way.)
This centralises a few things that multiple header files were
previously defining, and were protecting against each other's
redefinition with ifdefs - small things like structs and typedefs. Now
all those things are in a defs.h which is by definition safe to
include _first_ (out of all the codebase-local headers) and only need
to be defined once.
This seems to be a knock-on effect of my recent reworking of the SSH
code to be based around queues and callbacks. The loop iteration
function in uxsftp.c (ssh_sftp_do_select) would keep going round its
select loop until something had happened on one of its file
descriptors, and then return to the caller in the assumption that the
resulting data might have triggered whatever condition the caller was
waiting for - and if not, then the caller checks, finds nothing
interesting has happened, and resumes looping with no harm done.
But now, when something happens on an fd, it doesn't _synchronously_
trigger the follow-up condition PSFTP was waiting for (which, at
startup time, happens to be back->sendok() starting to return TRUE).
Instead, it schedules a callback, which will schedule a callback,
which ... ends up setting that flag. But by that time, the loop
function has already returned, the caller has found nothing
interesting and resumed looping, and _now_ the interesting thing
happens but it's too late because ssh_sftp_do_select will wait until
the next file descriptor activity before it next returns.
Solution: give run_toplevel_callbacks a return value which says
whether it's actually done something, and if so, return immediately in
case that was the droid the caller was looking for. As it were.
NFC for the moment, because the bufchain is always specially
constructed to hold exactly the same data that would have been passed
in to the function as a (pointer,length) pair. But this API change
allows get_userpass_input to express the idea that it consumed some
but not all of the data in the bufchain, which means that later on
I'll be able to point the same function at a longer-lived bufchain
containing the full stream of keyboard input and avoid dropping
keystrokes that arrive too quickly after the end of an interactive
password prompt.
This is a set of convenience wrappers around the existing toplevel
callback function, which arranges to avoid scheduling a second call to
a callback function if one is already in the queue.
Just like the last few commits, this is a piece of infrastructure that
nothing is yet using. But it will.
NFC: this is a preliminary refactoring, intended to make my life
easier when I start changing around the APIs used to pass user
keyboard input around. The fewer functions even _have_ such an API,
the less I'll have to do at that point.
Thanks to Jiri Kaspar for sending this patch (apart from the new docs
section, which is in my own words), which implements a feature we've
had as a wishlist item ('utf8-plus-vt100') for a long time.
I was actually surprised it was possible to implement it in so few
lines of code! I'd forgotten, or possibly never noticed in the first
place, that even in UTF-8 mode PuTTY not only accepts but still
_processes_ all the ISO 2022 control sequences and shift characters,
and keeps running track of all the same state in term->cset and
term->cset_attrs that it tracks in IS0-2022-enabled modes. It's just
that in UTF-8 mode, at the very last minute when a character+attribute
pair is about to be written into the terminal's character buffer, it
deliberately ignores the contents of those variables.
So all that was needed was a new flag checked at that last moment
which causes it not quite to ignore them after all, and bingo,
utf8-plus-vt100 is supported. And it works no matter which ISO 2022
sequences you're using; whether you're using ESC ( 0 to select the
line drawing set directly into GL and ESC ( B to get back when you're
done, or whether you send a preliminary ESC ( B ESC ) 0 to get GL/GR
to be ASCII and line drawing respectively so you can use SI and SO as
one-byte mode switches thereafter, both work just as well.
This implementation strategy has a couple of consequences, which I
don't think matter very much one way or the other but I document them
just in case they turn out to be important later:
- if an application expecting this mode has already filled your
terminal window with lqqqqqqqqk, then enabling this mode in Change
Settings won't retroactively turn them into the line drawing
characters you wanted, because no memory is preserved in the screen
buffer of what the ISO 2022 state was when they were printed. So
the application still has to do a screen refresh.
- on the other hand, if you already sent the ESC ( 0 or whatever to
put the terminal _into_ line drawing mode, and then you turn on
this mode in Change Settings, you _will_ still be in line drawing
mode, because the system _does_ remember your current ISO 2022
state at all times, whether it's currently applying it to output
printing characters or not.
Commit d515e4f1a went through a lot of very different shapes before it
was finally pushed. In some of them, GSS kex had its own value in the
kex enumeration, but it was used in ssh.c but not in config.c
(because, as in the final version, it wasn't configured by the same
drag-list system as the rest of them). So we had to distinguish the
set of key exchange ids known to the program as a whole from the set
controllable in the configuration.
In the final version, GSS kex ended up even more separated from the
kex enumeration than that: the enum value KEX_GSS_SHA1_K5 isn't used
at all. Instead, GSS key exchange appears in the list at the point of
translation from the list of enum values into the list of pointers to
data structures full of kex methods.
But after all the changes, everyone involved forgot to revert the part
of the patch which split KEX_MAX in two and introduced the pointless
value KEX_GSS_SHA1_K5! Better late than never: I'm reverting it now,
to avoid confusion, and because I don't have any reason to think the
distinction will be useful for any other purpose.
The former has advantages in terms of keeping Kerberos credentials up
to date, but it also does something sufficiently weird to the usual
SSH host key system that I think it's worth making sure users have a
means of turning it off separately from the less intrusive GSS
userauth.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
This is a preliminary refactoring for an upcoming change which will
need to affect every use of schedule_timer to wait for the next rekey:
those calls to schedule_timer are now centralised into a function that
does an organised piece of thinking about when the next timer should
be.
A side effect of this change is that the translation from
CONF_ssh_rekey_time to an actual tick count is now better proofed
against integer overflow (just in case the user entered a completely
silly value).
This is a mild security measure against malicious clipboard-writing.
It's only mild, because of course there are situations in which even a
sanitised paste could be successfully malicious (imagine someone
managing to write the traditional 'rm -rf' command into your clipboard
when you were going to paste to a shell prompt); but it at least
allows pasting into typical text editors without also allowing the
control sequence that exits the editor UI and returns to the shell
prompt.
This is a configurable option, because there's no well defined line to
be drawn between acceptable and unacceptable pastes, and it's very
plausible that users will have sensible use cases for pasting things
outside the list of permitted characters, or cases in which they know
they trust the clipboard-writer. I for one certainly find it useful on
occasion to deliberately construct a paste containing control
sequences that automate a terminal-based UI.
While I'm at it, when bracketed paste mode is enabled, we also prevent
pasting of data that includes the 'end bracketed paste' sequence
somewhere in the middle. I really _hope_ nobody was treating bracketed
paste mode as a key part of their security boundary, but then again, I
also can't imagine that anyone had an actually sensible use case for
deliberately making a bracketed paste be only partly bracketed, and
it's an easy change while I'm messing about in this area anyway.
On all platforms, you can now configure which clipboard the mouse
pastes from, which clipboard Ctrl-Ins and Shift-Ins access, and which
Ctrl-Shift-C and Ctrl-Shift-V access. In each case, the options are:
- nothing at all
- a clipboard which is implicitly written by the act of mouse
selection (the PRIMARY selection on X, CLIP_LOCAL everywhere else)
- the standard clipboard written by explicit copy/paste UI actions
(CLIPBOARD on X, the unique system clipboard elsewhere).
Also, you can control whether selecting text with the mouse _also_
writes to the explicitly accessed clipboard.
The wording of the various messages changes between platforms, but the
basic UI shape is the same everywhere.
This stores the last text selected in _this_ terminal, regardless of
whether any other application has since taken back whatever system
clipboard we also copied it to. It's written unconditionally whenever
text is selected in terminal.c.
The main purpose of this will be that it's also the place that you can
go and find the data you need to write to a system clipboard in
response to an explicit Copy operation. But it can also act as a data
source for pastes in its own right, so you can use it to implement an
intra-window private extra clipboard if that's useful. (OS X Terminal
has one of those, so _someone_ at least seems to like the idea.)
This lays some groundwork for making PuTTY's cut and paste handling
more flexible in the area of which clipboard(s) it reads and writes,
if more than one is available on the system.
I've introduced a system of list macros which define an enumeration of
integer clipboard ids, some defined centrally in putty.h (at present
just a CLIP_NULL which never has any text in it, because that seems
like the sort of thing that will come in useful for configuring a
given copy or paste UI action to be ignored) and some defined per
platform. All the front end functions that copy and paste take a
clipboard id, and the Terminal structure is now configured at startup
to tell it which clipboard id it should paste from on a mouse click,
and which it should copy from on a selection.
However, I haven't actually added _real_ support for multiple X11
clipboards, in that the Unix front end supports a single CLIP_SYSTEM
regardless of whether it's in OS X or GTK mode. So this is currently a
NFC refactoring which does nothing but prepare the way for real
changes to come.
It's actually a function specific to the Windows front end, and has
been all along - but I've only just noticed that no other front end
either uses it or defines it.
Previously, both the Unix and Windows front ends would respond to a
paste action by retrieving data from the system clipboard, converting
it appropriately, _storing_ it in a persistent dynamic data block
inside the front end, and then calling term_do_paste(term), which in
turn would call back to the front end via get_clip() to retrieve the
current contents of that stored data block.
But, as far as I can tell, this was a completely pointless mechanism,
because after a data block was written into this storage area, it
would be immediately used for exactly one paste, and then never
accessed again until the next paste action caused it to be freed and
replaced with a new chunk of pasted data.
So why on earth was it stored persistently at all, and why that
callback mechanism from frontend to terminal back to frontend to
retrieve it for the actual paste action? I have no idea. This change
removes the entire system and replaces it with the completely obvious
alternative: the character-set-converted version of paste data is
allocated in a _local_ variable in the frontend paste functions,
passed directly to term_do_paste which now takes (buffer,length)
parameters, and freed immediately afterwards. get_clip() is gone.
This is another piece of long-overdue refactoring similar to the
recent commit e3796cb77. But where that one dealt with normalisation
of stuff already stored _in_ a Conf by whatever means (including, in
particular, handling a user typing 'username@host.name' into the
Hostname box of the GUI session dialog box), this one deals with
handling argv entries and putting them into the Conf.
This isn't exactly a pure no-functional-change-at-all refactoring. On
the other hand, it isn't a full-on cleanup that completely
rationalises all the user-visible behaviour as well as the code
structure. It's somewhere in between: I've preserved all the behaviour
quirks that I could imagine a reason for having intended, but taken
the opportunity to _not_ faithfully replicate anything I thought was
clearly just a bug.
So, for example, the following inconsistency is carefully preserved:
the command 'plink -load session nextword' treats 'nextword' as a host
name if the loaded session hasn't provided a hostname already, and
otherwise treats 'nextword' as the remote command to execute on the
already-specified remote host, but the same combination of arguments
to GUI PuTTY will _always_ treat 'nextword' as a hostname, overriding
a hostname (if any) in the saved session. That makes some sense to me
because of the different shapes of the overall command lines.
On the other hand, there are two behaviour changes I know of as a
result of this commit: a third argument to GUI PuTTY (after a hostname
and port) now provokes an error message instead of being silently
ignored, and in Plink, if you combine a -P option (specifying a port
number) with the historical comma-separated protocol selection prefix
on the hostname argument (which I'd completely forgotten even existed
until this piece of work), then the -P will now override the selected
protocol's default port number, whereas previously the default port
would win. For example, 'plink -P 12345 telnet,hostname' will now
connect via Telnet to port 12345 instead of to port 23.
There may be scope for removing or rethinking some of the command-
line syntax quirks in the wake of this change. If we do decide to do
anything like that, then hopefully having it all in one place will
make it easier to remove or change things consistently across the
tools.
A more or less identical piece of code to sanitise the CONF_host
string prior to session launch existed in Windows PuTTY and both
Windows and Unix Plink. It's long past time it was centralised.
While I'm here, I've added a couple of extra comments in the
centralised version, including one that - unfortunately - tries _but
fails_ to explain why a string of the form "host.name:1234" doesn't
get the suffix moved into CONF_port the way "user@host" moves the
prefix into CONF_username. Commit c1c1bc471 is the one I'm referring
to in the comment, and unfortunately it has an unexplained one-liner
log message from before I got into the habit of being usefully
verbose.
It's an incoherent concept! There should not be any such thing as an
error box that terminates the entire program but is not modal. If it's
bad enough to terminate the whole program, i.e. _all_ currently live
connections, then there's no point in permitting progress to continue
in windows other than the affected one, because all windows are
affected anyway.
So all previous uses of fatalbox() have become modalfatalbox(), except
those which looked to me as if they shouldn't have been fatal in the
first place, e.g. lingering pieces of error handling in winnet.c which
ought to have had the severity of 'give up on this particular Socket
and close it' rather than 'give up on the ENTIRE UNIVERSE'.
This is used when you're about to destroy an object that is
(potentially) the context parameter for some still-pending toplevel
callback. It causes callbacks.c to go through its pending list and
delete any callback records referring to that context parameter, so
that when you destroy the object those callbacks aren't still waiting
to cause stale-pointer dereferences.
I've done this on a 'where possible' basis: in Windows paletted mode
(in case anyone is still using an old enough graphics card to need
that!) I simply haven't bothered, and will completely ignore the dim
flag.
Markus Gans points out that some applications which (not at all
unreasonably) don't trust $TERM to tell them the full capabilities of
their terminal will use the sequence "OSC 4 ; nn ; ? BEL" to ask for
the colour-palette value in position nn, and they may not particularly
care _what_ the results are but they will use them to decide whether
the right number of colour palette entries even exist.
I know some users don't like any colour _at all_, and we have a
separate option to turn off xterm-style 256-colour sequences, so it
seems remiss not to have an option to disable true colour as well.
This is a heavily rewritten version of a patch originally by Lorenz
Diener; it was tidied up somewhat by Christian Brabandt, and then
tidied up more by me. The basic idea is to add to the termchar
structure a pair of small structs encoding 24-bit RGB values, each
with a flag indicating whether it's turned on; if it is, it overrides
any other specification of fg or bg colour for that character cell.
I've added a test line to colours.txt containing a few example colours
from /usr/share/X11/rgb.txt. In fact it makes quite a good demo to run
the whole of rgb.txt through this treatment, with a command such as
perl -pe 's!^\s*(\d+)\s+(\d+)\s+(\d+).*$!\e[38;2;$1;$2;$3m$&\e[m!' rgb.txt
It's a function that exists on all platforms, not just on Unix - it's
used in ldisc.c - so it shouldn't have been declared only in unix.h.
Score another for clang's warnings.
Now, instead of returning a boolean indicating whether the query has
completed or is still pending, agent_query() returns NULL to indicate
that the query _has_ completed, and if it hasn't, it returns a pointer
to a context structure representing the pending query, so that the
latter can be used to cancel the query if (for example) you later
decide you need to free the thing its callback was using as a context.
This should fix a potential race-condition segfault if you overload an
agent forwarding channel and then close it abruptly. (Which nobody
will be doing for sensible purposes, of course! But I ran across this
while stress-testing other aspects of agent forwarding.)
I can't believe this codebase is around 20 years old and has had
multiple giant const-fixing patches, and yet there are _still_ things
that should have been const for years and aren't.
The UI now only has "1" and "2" options for SSH protocol version, which
behave like the old "1 only" and "2 only" options; old
SSH-N-with-fallback settings are interpreted as SSH-N-only.
This prevents any attempt at a protocol downgrade attack.
Most users should see no difference; those poor souls who still have to
work with SSH-1 equipment now have to explicitly opt in.
A compiler warning drew my attention to the fact that 'next' in
pinger_schedule() was an int, not the unsigned long it should have
been. And looking at the code that handles it, it was also taking no
care with integer wraparound when checking whether an existing
scheduled ping should be moved forward.
So now I do something a bit more robust, by remembering what time it
_was_ when we set pinger->next, and checking if the new time value
falls in the interval between those two times.
E.g. you might pass '--random-device=/dev/urandom'.
Mostly because I got sick of waiting for /dev/random to finish
blocking while I was trying to generate throwaway keys for testing bug
fixes in cmdgen itself. But it might also be useful on systems that
call their random device by a different name that we haven't
encountered.
(Since cmdgen also reads the saved PuTTY random seed file, setting
this option to /dev/zero will not render key generation deterministic.
It's tempting to provide _some_ way to do that, for testing purposes
and clearly marked as dangerous of course, but I think it would take
more faff than this.)
If you're connecting to a new server and it _only_ provides host key
types you've configured to be below the warning threshold, it's OK to
give the standard askalg() message. But if you've newly demoted a host
key type and now reconnect to some server for which that type was the
best key you had cached, the askalg() wording isn't really appropriate
(it's not that the key we've settled on is the first type _supported
by the server_, it's that it's the first type _cached by us_), and
also it's potentially helpful to list the better algorithms so that
the user can pick one to cross-certify.
Now we actually have enough of them to worry about, and especially
since some of the types we support are approved by organisations that
people might make their own decisions about whether to trust, it seems
worth having a config list for host keys the same way we have one for
kex types and ciphers.
To make room for this, I've created an SSH > Host Keys config panel,
and moved the existing host-key related configuration (manually
specified fingerprints) into there from the Kex panel.
It has three settings: on, off, and 'only until session starts'. The
idea of the last one is that if you use something like 'ssh -v' as
your proxy command, you probably wanted to see the initial SSH
connection-setup messages while you were waiting to see if the
connection would be set up successfully at all, but probably _didn't_
want a slew of diagnostics from rekeys disrupting your terminal in
mid-emacs once the session had got properly under way.
Default is off, to avoid startling people used to the old behaviour. I
wonder if I should have set it more aggressively, though.
This saves the need to fork and exec "cat", which should speed things
up. It also ensures that the network output goes to /dev/null, which
should avoid problems with blocking when writing to a full pipe.
A Plink invocation of the form 'plink -shareexists <session>' tests
for a currently live connection-sharing upstream for the session in
question. <session> can be any syntax you'd use with Plink to make the
actual connection (a host/port number, a bare saved session name,
-load, whatever).
I envisage this being useful for things like adaptive proxying - e.g.
if you want to connect to host A which you can't route to directly,
and you might already have a connection to either of hosts B or C
which are viable proxies, then you could write a proxy shell script
which checks whether you already have an upstream for B or C and goes
via whichever one is currently active.
Testing for the upstream's existence has to be done by actually
connecting to its socket, because on Unix the mere existence of a
Unix-domain socket file doesn't guarantee that there's a process
listening to it. So we make a test connection, and then immediately
disconnect; hence, that shows up in the upstream's event log.
On Windows, colons are illegal in filenames, because they're part of
the path syntax. But colons can appear in automatically constructed
log file names, if an IPv6 address is expanded from the &H placeholder.
Now we coerce any such illegal characters to '.', which is a bit of a
bodge but should at least cause a log file to be generated.
Personally I like using Command as the Esc-prefixing Meta key in
terminal sessions, because it occupies the same physical keyboard
position as the Alt key that I'm used to using on non-Macs. OS X
Terminal uses Option for that purpose (freeing up Command for the
conventional Mac keyboard shortcuts, of course), so I anticipate
differences of opinion.
Hence, here's a pair of OSX-specific config options which permit a
user to set either, or neither, or both of those modifier keys to
function as the terminal Meta key.
The general plan is that if PuTTY knows a host key for a server, it
should preferentially ask for the same type of key so that there's some
chance of actually getting the same key again. This should mean that
when a server (or PuTTY) adds a new host key type, PuTTY doesn't
gratuitously switch to that key type and then warn the user about an
unrecognised key.
Having found a lot of unfixed constness issues in recent development,
I thought perhaps it was time to get proactive, so I compiled the
whole codebase with -Wwrite-strings. That turned up a huge load of
const problems, which I've fixed in this commit: the Unix build now
goes cleanly through with -Wwrite-strings, and the Windows build is as
close as I could get it (there are some lingering issues due to
occasional Windows API functions like AcquireCredentialsHandle not
having the right constness).
Notable fallout beyond the purely mechanical changing of types:
- the stuff saved by cmdline_save_param() is now explicitly
dupstr()ed, and freed in cmdline_run_saved.
- I couldn't make both string arguments to cmdline_process_param()
const, because it intentionally writes to one of them in the case
where it's the argument to -pw (in the vain hope of being at least
slightly friendly to 'ps'), so elsewhere I had to temporarily
dupstr() something for the sake of passing it to that function
- I had to invent a silly parallel version of const_cmp() so I could
pass const string literals in to lookup functions.
- stripslashes() in pscp.c and psftp.c has the annoying strchr nature
All the name strings in ssh_cipher, ssh_mac, ssh_hash, ssh_signkey
point to compile-time string literals, hence should obviously be const
char *.
Most of these const-correctness patches are just a mechanical job of
adding a 'const' in the one place you need it right now, and then
chasing the implications through the code adding further consts until
it compiles. But this one has actually shown up a bug: the 'algorithm'
output parameter in ssh2_userkey_loadpub was sometimes returning a
pointer to a string literal, and sometimes a pointer to dynamically
allocated memory, so callers were forced to either sometimes leak
memory or sometimes free a bad thing. Now it's consistently
dynamically allocated, and should be freed everywhere too.
PuTTY now uses the updated version of Diffie-Hellman group exchange,
except for a few old OpenSSH versions which Darren Tucker reports only
support the old version.
FIXME: this needs further work because the Bugs config panel has now
overflowed.
I'm not actually sure why we've always had back ends notify ldisc of
changes to echo/edit settings by giving ldisc_send(ldisc,NULL,0,0) a
special meaning, instead of by having a separate dedicated notify
function with its own prototype and parameter set. Coverity's recent
observation that the two kinds of call don't even have the same
requirements on the ldisc (particularly, whether ldisc->term can be
NULL) makes me realise that it's really high time I separated the two
conceptually different operations into actually different functions.
While I'm here, I've renamed the confusing ldisc_update() function
which that special operation ends up feeding to, because it's not
actually a function applying to an ldisc - it applies to a front end.
So ldisc_send(ldisc,NULL,0,0) is now ldisc_echoedit_update(ldisc), and
that in turn figures out the current echo/edit settings before passing
them on to frontend_echoedit_update(). I think that should be clearer.
This provides support for ECDSA public keys, for both hosts and users,
and also ECDH key exchange. Supported curves are currently just the
three NIST curves required by RFC 5656.
This option is available from the command line as '-hostkey', and is
also configurable through the GUI. When enabled, it completely
replaces all of the automated host key management: the server's host
key will be checked against the manually configured list, and the
connection will be allowed or disconnected on that basis, and the host
key store in the registry will not be either consulted or updated.
The main aim is to provide a means of automatically running Plink,
PSCP or PSFTP deep inside Windows services where HKEY_CURRENT_USER
isn't available to have stored the right host key in. But it also
permits you to specify a list of multiple host keys, which means a
second use case for the same mechanism will probably be round-robin
DNS names that select one of several servers with different host keys.
Host keys can be specified as the standard MD5 fingerprint or as an
SSH-2 base64 blob, and are canonicalised on input. (The base64 blob is
more unwieldy, especially with Windows command-line length limits, but
provides a means of specifying the _whole_ public key in case you
don't trust MD5. I haven't bothered to provide an analogous mechanism
for SSH-1, on the basis that anyone worrying about MD5 should have
stopped using SSH-1 already!)
[originally from svn r10220]
We now expect that after the server has sent us CHANNEL_CLOSE, we
should not expect to see any replies to our outstanding channel
requests, and conversely after we have sent CHANNEL_CLOSE we avoid
sending any reply to channel requests from the server. This was the
consensus among implementors discussing the problem on ietf-ssh in
April 2014.
To cope with current OpenSSH's (and perhaps other servers we don't
know about yet) willingness to send request replies after
CHANNEL_CLOSE, I introduce a bug-compatibility flag which is detected
for every OpenSSH version up to and including the current 6.6 - but
not beyond, since https://bugzilla.mindrot.org/show_bug.cgi?id=1818
promises that 6.7 will also implement the new consensus behaviour.
[originally from svn r10200]
The basic strategy is described at the top of the new source file
sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain
socket or Windows named pipe, and listens for connections from other
PuTTYs wanting to run sessions on the same server. The protocol spoken
down that socket/pipe is essentially the bare ssh-connection protocol,
using a trivial binary packet protocol with no encryption, and the
upstream has to do some fiddly transformations that I've been
referring to as 'channel-number NAT' to avoid resource clashes between
the sessions it's managing.
This is quite different from OpenSSH's approach of using the Unix-
domain socket as a means of passing file descriptors around; the main
reason for that is that fd-passing is Unix-specific but this system
has to work on Windows too. However, there are additional advantages,
such as making it easy for each downstream PuTTY to run its own
independent set of port and X11 forwardings (though the method for
making the latter work is quite painful).
Sharing is off by default, but configuration is intended to be very
easy in the normal case - just tick one box in the SSH config panel
and everything else happens automatically.
[originally from svn r10083]
This change attempts to reinstate as a universal property something
which was sporadically true of the ad-hockery that came before
toplevel callbacks: that if there's a _very long_ queue of things to
be done through the callback mechanism, the doing of them will be
interleaved with re-checks of other event sources, which might (e.g.)
cause a flag to be set which makes the next callback decide not to do
anything after all.
[originally from svn r10040]
I've removed the ad-hoc front-end bodgery in the Windows and GTK ports
to arrange for term_paste to be called at the right moments, and
instead, terminal.c itself deals with knowing when to send the next
chunk of pasted data using a combination of timers and the new
top-level callback mechanism.
As a happy side effect, it's now all in one place so I can actually
understand what it's doing! It turns out that what all that confusing
code was up to is: send a line of pasted data, and delay sending the
next line until either a CR or LF is returned from the server
(typically indicating that the pasted text has been received and
echoed) or 450ms elapse, whichever comes first.
[originally from svn r10020]
This is a little like schedule_timer, in that the callback you provide
will be run from the top-level message loop of whatever application
you're in; but unlike the timer mechanism, it will happen
_immediately_.
The aim is to provide a general way to avoid re-entrance of code, in
cases where just _doing_ the thing you want done is liable to trigger
a confusing recursive call to the function in which you came to the
decision to do it; instead, you just request a top-level callback at
the message loop's earliest convenience, and do it then.
[originally from svn r10019]
that the user really ought to know but that are not actually fatal to
continued operation of PuTTY or a single network connection.
[originally from svn r9932]
First, make absolute times unsigned. This means that it's safe to
depend on their overflow behaviour (which is undefined for signed
integers). This requires a little extra care in handling comparisons,
but I think I've correctly adjusted them all.
Second, functions registered with schedule_timer() are guaranteed to be
called with precisely the time that was returned by schedule_timer().
Thus, it's only necessary to check these values for equality rather than
doing risky range checks, so do that.
The timing code still does lots that's undefined, unnecessary, or just
wrong, but this is a good start.
[originally from svn r9667]
winadj@putty.projects.tartarus.org request. Not currently enabled
automatically, but should be usable as a manual workaround.
[originally from svn r9592]
zero but does it in such a way that over-clever compilers hopefully
won't helpfully optimise the call away if you do it just before
freeing something or letting it go out of scope. Use this for
(hopefully) every memset whose job is to destroy sensitive data that
might otherwise be left lying around in the process's memory.
[originally from svn r9586]
UTF-16 support. High Unicode characters in the terminal are now
converted back into surrogates during copy and draw operations, and
the Windows drawing code takes account of that when splitting up the
UTF-16 string for display. Meanwhile, accidental uses of wchar_t have
been replaced with 32-bit integers in parts of the cross-platform code
which were expecting not to have to deal with UTF-16.
[originally from svn r9409]
allocated type.
The main reason for this is to stop it from taking up a fixed large
amount of space in every 'struct value' subunion in conf.c, although
that makes little difference so far because Filename is still doing
the same thing (and is therefore next on my list). However, the
removal of its arbitrary length limit is not to be sneezed at.
[originally from svn r9314]
data channels. Should comprehensively fix 'half-closed', in principle,
though it's a big and complicated change and so there's a good chance
I've made at least one mistake somewhere.
All connections should now be rigorous about propagating end-of-file
(or end-of-data-stream, or socket shutdown, or whatever) independently
in both directions, except in frontends with no mechanism for sending
explicit EOF (e.g. interactive terminal windows) or backends which are
basically always used for interactive sessions so it's unlikely that
an application would be depending on independent EOF (telnet, rlogin).
EOF should now never accidentally be sent while there's still buffered
data to go out before it. (May help fix 'portfwd-corrupt', and also I
noticed recently that the ssh main session channel can accidentally
have MSG_EOF sent before the output bufchain is clear, leading to
embarrassment when it subsequently does send the output).
[originally from svn r9279]
'Config' in putty.h, which stores all PuTTY's settings and includes an
arbitrary length limit on every single one of those settings which is
stored in string form. In place of it is 'Conf', an opaque data type
everywhere outside the new file conf.c, which stores a list of (key,
value) pairs in which every key contains an integer identifying a
configuration setting, and for some of those integers the key also
contains extra parts (so that, for instance, CONF_environmt is a
string-to-string mapping). Everywhere that a Config was previously
used, a Conf is now; everywhere there was a Config structure copy,
conf_copy() is called; every lookup, adjustment, load and save
operation on a Config has been rewritten; and there's a mechanism for
serialising a Conf into a binary blob and back for use with Duplicate
Session.
User-visible effects of this change _should_ be minimal, though I
don't doubt I've introduced one or two bugs here and there which will
eventually be found. The _intended_ visible effects of this change are
that all arbitrary limits on configuration strings and lists (e.g.
limit on number of port forwardings) should now disappear; that list
boxes in the configuration will now be displayed in a sorted order
rather than the arbitrary order in which they were added to the list
(since the underlying data structure is now a sorted tree234 rather
than an ad-hoc comma-separated string); and one more specific change,
which is that local and dynamic port forwardings on the same port
number are now mutually exclusive in the configuration (putting 'D' in
the key rather than the value was a mistake in the first place).
One other reorganisation as a result of this is that I've moved all
the dialog.c standard handlers (dlg_stdeditbox_handler and friends)
out into config.c, because I can't really justify calling them generic
any more. When they took a pointer to an arbitrary structure type and
the offset of a field within that structure, they were independent of
whether that structure was a Config or something completely different,
but now they really do expect to talk to a Conf, which can _only_ be
used for PuTTY configuration, so I've renamed them all things like
conf_editbox_handler and moved them out of the nominally independent
dialog-box management module into the PuTTY-specific config.c.
[originally from svn r9214]
information about where to put items that aren't mentioned in the
saved configuration. So far the only nontrivial use I've made of this
facility is to default to placing KEX_RSA just above KEX_WARN in the
absence of any other information, which should fix
'ssh2-rsa-kex-pref'.
While I'm here I've rewritten wprefs() on general principles to remove
the needless length limit, since I was touching it anyway. The length
limit is still in gprefs (but I've lengthened it just in case).
[originally from svn r9181]
in saved sessions, so that a programmable window manager can
distinguish different PuTTYs/pterms on startup and assign them
different window management properties.
[originally from svn r9078]
icon, even if the program isn't running at the time, to be presented
with an application-defined collection of helpful links). The current
jump list is updated every time a saved session is loaded, and shows
the last few launchable saved sessions (i.e. not those like Default
Settings) that were loaded. Also, if Pageant or PuTTYgen or both is in
the same directory as the PuTTY binary, the jump list will present
links to launch those too.
Based on a patch sent last year by Daniel B. Roy, though it's barely
recognisable any more...
[originally from svn r9046]
are now loaded from standard locations (system32 for SSPI, the
registry-stored MIT KfW install location for KfW) rather than using
the risky default DLL search path; I've therefore also added an
option to manually specify a GSS DLL we haven't heard of (which
should in principle Just Work provided it supports proper GSS-API as
specified in the RFC). The same option exists on Unix too, because
it seemed like too useful an idea to reserve to Windows. In
addition, GSSAPI is now documented, and also (unfortunately) its GUI
configuration has been moved out into a sub-subpanel on the grounds
that it was too big to fit in Auth.
[originally from svn r9003]
reorganises the GSSAPI support so that it handles alternative
implementations of the GSS-API. In particular, this means PuTTY can
now talk to MIT Kerberos for Windows instead of being limited to
SSPI. I don't know for sure whether further tweaking will be needed
(to the UI, most likely, or to automatic selection of credentials),
but testing reports suggest it's now at least worth committing to
trunk to get it more widely tested.
[originally from svn r8952]
today reported an SSH2_MSG_UNIMPLEMENTED from a Cisco router which
looks as if it was triggered by SSH2_MSG_IGNORE, so I'm
experimentally putting this flag in. Currently must be manually
enabled, though if it turns out to solve the user's problem then
I'll probably add at least one version string...
[Edited commit message: actually, I also committed in error a piece
of experimental code as part of this checkin. Serve me right for not
running 'svn diff' first.]
[originally from svn r8926]
function in terminal.c, and replace the cloned-and-hacked handling
code in all our front ends with calls to that.
This was intended for code cleanliness, but a side effect is to make
the GTK arrow-key handling support disabling of application cursor
key mode in the Features panel. Previously that checkbox was
accidentally ignored, and nobody seems to have noticed before!
[originally from svn r8896]
if we have no better ideas, with UI shamelessly stolen from Quest PuTTY.
Off by default, which effectively reverts the change to using the local
username by default that came in with GSSAPI support in r8138. Anyone wanting
seamless single sign-on will need to set the new option. (The previous
default behaviour was getting in the way in ad-hoc scenarios.)
Note that the PSCP and Unix-Plink behaviour of using the local username by
default have remained unchanged throughout; they are not affected by the new
option. Not sure if that's the Right Thing.
[originally from svn r8324]
[r8138 == de5dd9d65c]
strings more rigorously, and then we look up the local X authority
data in .Xauthority _ourself_ rather than delegating to an external
xauth program. This is (negligibly) more efficient on Unix, assuming
I haven't got it wrong in some subtle way, but its major benefit is
that we can now support X authority lookups on Windows as well
provided the user points us at an appropriate X authority file in
the standard format. A new Windows-specific config option has been
added for this purpose.
[originally from svn r8305]
both directions. We had a bug report yesterday about a Cisco router
sending SSH2_MSG_UNIMPLEMENTED and it wasn't clear for which packet;
logging the sequence numbers should make such problems much easier
to diagnose.
(In fact this logging fix wouldn't have helped in yesterday's case,
because the router also didn't bother to fill in the sequence number
field in the SSH2_MSG_UNIMPLEMENTED packet! This is a precautionary
measure against the next one of these problems.)
[originally from svn r8295]
no actual prompts, we weren't displaying the former, which was wrong. We
should now (although I haven't found a server to test it against).
[originally from svn r8172]
to manually tweak the host name and port number under which the SSH
host key is read and written.
I've put it in the cross-platform Connection panel. Partly under the
flimsy pretext that other backends _can_ use it if they so wish (and
in fact it overrides the host name for title-bar purposes in all
network backends, though it has no other effect in anything but
SSH); but mostly because the SSH panel was too full already :-)
[originally from svn r8033]
advertise so that the server can't exceed our maximum packet size.
Enable it for "1.36_sshlib GlobalSCAPE" which apparently sends oversize
packets otherwise.
[originally from svn r7804]
channel, arrange to set the SSH-2 window size to something very
large. This prevents the connection stalling when the window fills
up, and means that PSCP receives data _much_ faster.
[originally from svn r7672]
Should be no significant change in behaviour.
(Well, entering usernames containing commas on Plink's command line will be
a little harder now.)
[originally from svn r7628]
launchable session without getting confused by it, we can relax the
restriction on storing a host name in DS, which has attracted a
steady stream of complaints over the past six or seven years.
[originally from svn r7266]
We now have an option where a remote window title query returns a well-formed
response containing the empty string. This should keep stop any server-side
application that was expecting a response from hanging, while not permitting
the response to be influenced by an attacker.
We also retain the ability to stay schtum. The existing checkbox has thus
grown into a set of radio buttons.
I've changed the default to the "empty string" response, even in the backward-
compatibility mode of loading old settings, which is a change in behaviour;
any users who want the old behaviour back will have to explicitly select it. I
think this is probably the Right Thing. (The only drawback I can think of is
that an attacker could still potentially use the relevant fixed strings for
mischief, but we already have other, similar reports.)
[originally from svn r7043]
easily manage, by adopting a hybrid approach to Unicode text
display. The old approach of simply calling ExtTextOutW provided
font linking without us having to lift a finger, but didn't do the
right thing when it came to bidirectional or Arabic-shaped text.
Arabeyes' replacement exact_textout() supported the latter, but
turned out to break the former (with no warning from the Windows API
documentation, so it's not their fault).
So now I've got a second wrapper layer called general_textout(),
which splits the input string into substrings based on bidi
character class. Any character liable to cause bidi or shaping
behaviour if fed straight to ExtTextOutW is instead fed through
Arabeyes' exact_textout(), but the rest is fed straight to
ExtTextOutW as it used to be.
The effect appears to be that font linking is restored for all
characters _except_ Arabic and other bidi scripts, which means in
particular that we are no longer in a state of regression over 0.57.
(0.57 would have done font linking on Arabic as well, but would also
have misbidied it, so we've merely exchanged one failure mode for
another slightly less harmful one in that situation.)
[originally from svn r6910]
in an SSH connection _in addition_ to the decrypted packets. This
will hopefully come in useful for debugging wire data corruption
issues: you can strace the server, enable this mode in the client,
and compare the sent and received data.
I'd _like_ to have this mode also log Diffie-Hellman private
exponents, session IDs, encryption and MAC keys, so that the
resulting log file could be used to independently verify the
correctness of all cryptographic operations performed by PuTTY.
However, I haven't been able to convince myself that the security
implications are acceptable. (It doesn't matter that this
information would permit an attacker to decrypt the session, because
the _already_ decrypted session is stored alongside it in the log
file. And I'm not planning, under any circumstances, to log users'
private keys. But gaining access to the log file while the session
was still running would permit an attacker to _hijack_ the session,
and that's the iffy bit.)
[originally from svn r6835]
there): `plink host -nc host2:port' causes the SSH connection's main
channel to be replaced with a direct-tcpip connection to the
specified destination. This feature is mainly designed for use as a
local proxy: setting your local proxy command to `plink %proxyhost
-nc %host:%port' lets you tunnel SSH over SSH with a minimum of
fuss. Works on all platforms.
[originally from svn r6823]
in place of making a network connection. This has involved a couple
of minor infrastructure changes:
- New dlg_label_change() function in the dialog.h interface, which
alters the label on a control. Only used, at present, to switch
the Host Name and Port boxes into Serial Line and Speed, which
means that any platform not implementing serial connections (i.e.
currently all but Windows) does not need to actually do anything
in this function. Yet.
- New small piece of infrastructure: cfg_launchable() determines
whether a Config structure describes a session ready to be
launched. This was previously determined by seeing if it had a
non-empty host name, but it has to check the serial line as well
so there's a centralised function for it. I haven't gone through
all front ends and arranged for this function to be used
everywhere it needs to be; so far I've only checked Windows.
- Similarly, cfg_dest() returns the destination of a connection
(host name or serial line) in a text format suitable for putting
into messages such as `Unable to connect to %s'.
[originally from svn r6815]
it's NULL. Since we already have one back end (uxpty) which doesn't
in fact talk to a network socket, and may well have more soon, I'm
replacing this TCP/IP-centric function with a nice neutral
`connected' function returning a boolean. Nothing else about its
semantics has currently changed.
[originally from svn r6810]
Pageant for local authentication. (This is a `don't use Pageant for
authentication at session startup' button rather than a `pretend
Pageant doesn't exist' button: that is, agent forwarding is
independent of this option.)
[originally from svn r6572]
basis for other terminal-involving applications: a stub
implementation of the printing interface, an additional function in
notiming.c, and also I've renamed the front-end function beep() to
do_beep() so as not to clash with beep() in lib[n]curses.
[originally from svn r6479]
abstracted out; replace loops structured around a single interaction
per loop with less tortuous code (fixes: `ki-multiprompt-crash',
`ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and
`proxy-password-prompt' easier).
The new interaction abstraction has a lot of fields that are unused in
the current code (things like window captions); this is groundwork for
`gui-auth'. However, ssh.c still writes directly to stderr; that may
want to be fixed.
In the GUI apps, user interaction is moved to terminal.c. This should
make it easier to fix things like UTF-8 username entry, although I
haven't attempted to do so. Also, control character filtering can be
tailored to be appropriate for individual front-ends; so far I don't
promise anything other than not having made it any worse.
I've tried to test this fairly exhaustively (although Mac stuff is
untested, as usual). It all seems to basically work, but I bet there
are new bugs. (One I know about is that you can no longer make the
PuTTY window go away with a ^D at the password prompt; this should be
fixed.)
[originally from svn r6437]
[this svn revision also touched putty-wishlist]
there are servers which could in principle operate in this mode, although I
don't know if any do in practice. (Hence, I haven't been able to test it.)
[originally from svn r5748]
[this svn revision also touched putty-wishlist]
Unix Plink sends everything sensible it can find, and it's fully configurable
from the GUI.
I'm not entirely sure about the precise set of modes that Unix Plink should
look at; informed tweaks are welcome.
Also the Mac bits are guesses (but trivial).
[originally from svn r5653]
[this svn revision also touched putty-wishlist]
that the global `sesslist' got out of sync with the saved-sessions submenu,
causing the latter to launch the wrong sessions.
Also, Change Settings wasn't getting a fresh session list, so if the set of
sessions had changed since session startup it wouldn't reflect that (at least
until a session was saved). Fixed (on all platforms).
Therefore, since the global sesslist didn't seem to be useful, I've got rid
of it; config.c creates one as needed, as do the frontends. (Not tried
compiling Mac changes.)
Also, we now build the saved-sessions submenu on demand on Windows and Unix.
(This should probably also be done on the Mac.)
[originally from svn r5609]
<http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c>.
This is identified both internally and in HTTP headers as 2003-05-20,
for Unicode 4.0.
Only changes from upstream are to make mk_wcwidth_cjk() non-static and to
#include "putty.h" for prototypes.
The status of some code points has changed; see the wishlist item. We've
had some feedback from the CJK and Arabic communities that upgrading is
probably the right thing to do.
[originally from svn r5547]
[this svn revision also touched putty-wishlist]
* All the PuTTY tools for Windows and Unix now contain the fingerprints of
the Master Keys. The method for accessing them is crude but universal:
a new "-pgpfp" command-line option. (Except Unix PuTTYgen, which takes
"--pgpfp" just to be awkward.)
* Move the key policy discussion from putty-website/keys.html to
putty/doc/pgpkeys.but, and autogenerate the former from the latter.
Also tweak the text somewhat and include the fingerprints of the
Master Keys themselves.
(I've merged the existing autogeneration scripts into a single new
one; I've left the old scripts and keys.html around until such time
as the webmonster reviews the changes and plumbs in the new script;
he should remove the old files then.)
[originally from svn r5524]
[this svn revision also touched putty-website]
discussed. Use Barrett and Silverman's convention of "SSH-1" for SSH protocol
version 1 and "SSH-2" for protocol 2 ("SSH1"/"SSH2" refer to ssh.com
implementations in this scheme). <http://www.snailbook.com/terms.html>
[originally from svn r5480]
This was harder than verify_ssh_host_key() and askalg() put
together, because:
(a) askappend() can be called at any time, since it's a side effect
of data-logging functions. Therefore there can be an unfinished
askappend() alert at any time, and hence the OS X front end has
to be prepared to _queue_ other alerts which occur during that
time.
(b) logging.c has to do something with data that comes in while
it's waiting for an answer to askappend(). It buffers it until
it knows what the user wants done with it. This involved
something of a reorganisation of logging.c.
[originally from svn r5344]
now returns an integer: 0 means cancel the SSH connection and 1
means continue with it. Additionally, they can return -1, which
means `front end has set an asynchronous alert box in motion, please
wait to be called back with the result', and each one is passed a
callback function pointer and context for this purpose.
I have not yet done the same to askappend() yet, because it will
take a certain amount of reorganisation of logging.c.
Importantly, this checkin means the host key dialog box now works on
OS X.
[originally from svn r5330]
changing its mouse pointer. Currently this is only used in the (slightly-
arbitrarily-defined) "heavy" bits of SSH-2 key exchange. We override pointer
hiding while PuTTY is busy, but preserve pointer-hiding state.
Not yet implemented on the Mac.
Also switch to frobbing window-class cursor in Windows rather than relying on
SetCursor().
[originally from svn r5303]
deal with rekeys at all: they totally ignore mid-session KEXINIT
sent by the client. Hence, a new bug entry so we don't try it.
[originally from svn r5092]
of polishing to bring them to what I think should in principle be
release quality. Unlike the unfix.org patches themselves, this
checkin enables IPv6 by default; if you want to leave it out, you
have to build with COMPAT=-DNO_IPV6.
I have tested that this compiles on Visual C 7 (so the nightlies
_should_ acquire IPv6 support without missing a beat), but since I
don't have IPv6 set up myself I haven't actually tested that it
_works_. It still seems to make correct IPv4 connections, but that's
all I've been able to verify for myself. Further testing is needed.
[originally from svn r5047]
[this svn revision also touched putty-wishlist]
mid-session if we are not using SSHv1. I've done this by introducing
a generic `cfg_info' function which every back end can use to
communicate an int's worth of data to setup_config_box; in SSH
that's the protocol version in use, and in everything else it's
currently zero.
[originally from svn r5040]
[r5031 == d77102a8d5]
(which will gain more content anon).
Retire BUG_SSH2_DH_GEX and add a backwards-compatibility wart, since we never
did find a way of automatically detecting this alleged server bug, and in any
case there was only ever one report (<3D91F3B5.7030309@inwind.it>, FWIW).
Also generalise askcipher() to a new askalg() (thus touching all the
front-ends).
I've made some attempt to document what SSH key exchange is and why you care,
but it could use some review for clarity (and outright lies).
[originally from svn r5022]
the start of every contiguous run passed to do_text() or
do_cursor(), and arranges never to overwrite only part of such a run
on the next update.
I'm a bit worried about this checkin because I've also completely
revamped cursor handling: the cursor was previously being drawn
_outside_ the main loop over the display line, and is now drawn as
part of that loop when it gets to the cursor location. It _seems_ to
still work sensibly, even in complex cases involving LATTR_WIDE and
double-width CJK characters etc, but I won't be entirely happy until
it's had some beta use.
[originally from svn r5003]
[this svn revision also touched putty-wishlist]
results in unacceptable performance for him on Win2000. Add a checkbox to
revert to the old behaviour.
[originally from svn r4988]
[this svn revision also touched putty-wishlist]
timing.c, and hence takes its own responsibility for calling
noise_regular() at regular intervals. Again, this means it will be
called consistently in _all_ the SSH-speaking tools, not just those
in which I remembered to call it!
[originally from svn r4913]
blink when the window doesn't have focus, we don't schedule blink
timers at that point either.
Infrastructure change: term->has_focus should now not be written
directly from outside terminal.c. Instead, use the function
term_set_focus, which will sort out the blink timers as well.
[originally from svn r4911]
which pretty much any module can call to request a call-back in the
future. So terminal.c can do its own handling of blinking, visual
bells and deferred screen updates, without having to rely on
term_update() being called 50 times a second (fixes: pterm-timer);
and ssh.c and telnet.c both invoke a new module pinger.c which takes
care of sending keepalives, so they get sent uniformly in all front
ends (fixes: plink-keepalives, unix-keepalives).
[originally from svn r4906]
[this svn revision also touched putty-wishlist]
of the SSH servers I conveniently have access to (Debian stable OpenSSH --
3.4p1 -- and lshd) seem to take a blind bit of notice, but the channel
requests look fine to me in the packet log.
I've included all the signals explicitly defined by
draft-ietf-secsh-connect-19, but I've put the more obscure ones in a submenu
of the specials menu; there's therefore been some minor upheaval to support
such submenus.
[originally from svn r4652]
the same window (Windows version only).
Policy change: it's now the backend's responsibility to call
update_specials_menu() at the start of a session (or whenever it feels ready),
if it has any special commands. Otherwise the menu won't be displayed.
[originally from svn r4649]
http://www.cl.cam.ac.uk/~mgk25/unicode.html#activate
feels strongly that it should be easy to make _all_ your
applications work in UTF-8 mode, without having to remember a switch
for each one. Every application should simply note a UTF-8 locale
setting and switch into UTF-8 mode automatically.
Therefore, for the Unix port only, there's now a checkbox, enabled
by default, which causes the drop-down Translation box to be
overridden if the locale indicates UTF-8. Anyone who doesn't like
this, or doesn't like MGK, is welcome to turn it straight back off.
I'm not _completely_ convinced by MGK's argument myself; for
xterm/pterm to do _useful_ UTF-8 you also need to specify a decently
Unicode-capable font, and there's no way _that_ can be automagically
done on noticing a locale setting. But it's a de facto standard
(i.e. xterm does it :-) so I might as well at least be _able_ to
support it.
[originally from svn r4648]
array of each `termline' structure now contains optional additional
entries after the normal number of columns, which are used to chain
a linked list of combining characters off any primary termchar that
needs it. This means we support arbitrarily many combining
characters per cell (unlike xterm's hard limit of 2).
Cut and paste works correctly (selecting a character cell containing
multiple code points causes all those code points to be cut and
pasted). Display works by simply overlaying all the relevant
characters on top of one another; this is good enough for Unix
(xterm does the same thing), and mostly seems OK for Windows except
that the Windows Unicode fonts have a nasty habit of not containing
most of the combining characters and thus overlaying an
unknown-code-point box on your perfectly good base glyph.
I had no idea how to add support in the Mac do_text(), so I've
simply stuck in an assertion that will trigger the first time a
combining character is displayed, and hopefully this will bite
someone with the clue to fix it.
[originally from svn r4622]
PuTTY / Plink not to run a remote shell/command at all. Supported in
the GUI configuration and via the (OpenSSH-like) -N command-line
option.
No effort is currently made to arrange `nice' UI properties. If you
do this in GUI PuTTY, a full-size terminal window will still be
created, and will sit there with almost nothing in it throughout
your session. If you do it in Plink, Plink will not accept any kind
of request to terminate gracefully; you'll have to ^C or kill it.
Nonetheless, even this little will be useful to some people...
[originally from svn r4614]
The active terminal screen is no longer an array of `unsigned long'
encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of
`termchar' structures, which currently have 32-bit Unicode and 32
attribute bits but which will probably expand further in future.
To prevent bloat of the memory footprint, I've introduced a mostly
RLE-like compression scheme for storing scrollback: each line is
compressed into a compact (but hard to modify) form when it moves
into the term->scrollback tree, and is temporarily decompressed when
the user wants to scroll back over it. My initial tests suggest that
this compression averages about 1/4 of the previous (32 bits per
character cell) data size in typical output, which means this is an
improvement even without counting the new ability to extend the
information stored in each character cell.
Another beneficial side effect is that the insane format in which
Unicode was passed to front ends through do_text() has now been
rendered sane.
Testing is incomplete; this _may_ still have instabilities. Windows
and Unix front ends both seem to work as far as I've looked, but I
haven't yet looked very hard. The Mac front end I've edited (it
seemed obvious how to change it) but I can't compile or test it.
As an immediate functional effect, the terminal emulator now
supports full 32-bit Unicode to whatever extent the host platform
allows it to. For example, if you output a 4-or-more-byte UTF-8
character in Unix pterm, it will not display it properly, but it
will correctly paste it back out in a UTF8_STRING selection. Windows
is more restricted, sadly.
[originally from svn r4609]
by default (although they can be included). There's also an option to remove
session data, which is good both for privacy and for reducing the size of
logfiles.
[originally from svn r4593]
when talking to SOCKS 5 proxies. Configures itself transparently (if
the proxy offers CHAP it will use it, otherwise it falls back to
ordinary cleartext passwords).
[originally from svn r4517]
`all session data' modes, without completely mauling the performance, by
fflush()ing once per term_out(). If anyone complains I suppose we can
make this optional.
[originally from svn r4445]
before "-load" is processed so that it doesn't clobber it.
I've also changed the semantics of "-load" slightly for PSCP, PSFTP,
and Plink: if it's specified at all, it overrides (disables) the
implicit loading of session details based on a supplied hostname
elsewhere (on the grounds that the user is more likely to want the
"-load" session than the implicit session). (PuTTY itself doesn't do
implicit loading at all, so I haven't changed it.)
This means that all the PuTTY tools' behaviour is now consistent iff
"-load" is specified (otherwise, some tools have implicit-session, and
others don't).
However, I've not documented this behaviour, as there's a good chance
it will be swept away if and when we get round to sorting out how we
deal with settings from multiple sources. It's intended as a "do
something sensible" change.
[originally from svn r4352]
No very good reason, but I've occasionally wanted to frob it to see if it
makes any difference to problems I'm having, and it was easy.
Tested that it does actually cause keepalives on Windows (with tcpdump);
should also work on Unix. Not implemented on Mac (does nothing), but then
neither is TCP_NODELAY.
Quite a big checkin, much of which is adding `keepalive' alongside `nodelay'
in network function calls.
[originally from svn r4309]
on Linux, but the (very few) platform-specific bits are already
abstracted out of the main code, so it should port to other
platforms with a minimum of fuss.
[originally from svn r3762]
platform-independent source file. Haven't yet added the extra
abstraction routines to uxsftp.c to create a Unix PSCP port, but it
shouldn't take long.
Also in this checkin, a change of semantics in platform_default_s():
now strings returned from it are expected to be dynamically allocated.
[originally from svn r3420]
by disabling bold-font-name guessing (if their bold fonts are ugly).
I've turned the UI inside out, but the meat is pretty much the same.
[originally from svn r3410]
discriminating on the Windows version in order to decide whether to
call MessageBeep(-1) or Beep() - I'd prefer to directly test the
specific OS property in any given case - but it looks as if this is
the best available option.
[originally from svn r3208]
box, in that it started to expand under the weight of proxy options.
Now fixed, by folding the SOCKS version selector into the general
proxy type selector so there's one single 5- or 6-way radio button
set split over two lines. settings.c has of course grown a backwards
compatibility wart to deal with legacy config data.
[originally from svn r3168]
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]
callback function; it may return 0 to indicate that it doesn't have
an answer _yet_, in which case it will call the callback later on
when it does, or it may return 1 to indicate that it's got an answer
right now. The Windows agent_query() implementation is functionally
unchanged and still synchronous, but the Unix one is async (since
that one was really easy to do via uxsel). ssh.c copes cheerfully
with either return value, so other ports are at liberty to be sync
or async as they choose.
[originally from svn r3153]
hazard. I considered removing it completely, but I can't rule out
the possibility of an OS that actually takes security of its
terminal devices seriously, and which might be able to make sensible
and safe use of this feature.
[originally from svn r3103]
of PuTTY (terminal, backend, logctx etc) take a `void *' handle
passed to them from the frontend, and used as a context for all
their callbacks. Most of these point at the frontend structure
itself (on platforms where this is meaningful), except that the
handle passed to the backend has always pointed at the terminal
because from_backend() was implemented in terminal.c. This has
finally bitten Unix PuTTY, because both backend and logctx have
been passing their respective and very different frontend handles to
logevent(), so I've fixed it.
from_backend() is now a function supplied by the _frontend_ itself,
in all cases, and the frontend handle passed to backends must be the
same as that passed to everything else. What was from_backend() in
terminal.c is now called term_data(), and the typical implementation
of from_backend() in a GUI frontend will just extract the terminal
handle from the frontend structure and delegate to that.
This appears to work on Unix and Windows, but has most likely broken
the Mac build.
[originally from svn r3100]
former by simply removing it; the latter by adding an enumeration
function to libcharset.) This has had slight `const' repercussions
on cp_name() and cp_enumerate() which might break the Mac build.
[originally from svn r3064]
This menu is not yet fully populated, but it has an About box (yet
another licence location :-/ ) and supports the new configurable
specials menu (thus making Unix PuTTY do one tiny thing which
OpenSSH-in-a-pterm can't :-).
[originally from svn r3062]
supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS
5 isn't supported, but it'll be no difficulty once I actually get
round to it). Thanks to Chas Honton for his `stone soup' patch: I
didn't end up actually using any of his code, but it galvanised me
into doing it properly myself :-)
[originally from svn r3055]
`Special Command' menu, in which any backend can place its own list
of magical things the user might want to ask the backend to do. In
particular I've implemented the recently proposed "break" extension
in SSH2 using this mechanism.
NB this checkin slightly breaks the Mac build, since it needs to
provide at least a stub form of update_specials_menu().
[originally from svn r3054]
think it's now actually usable as a day-to-day SSH client, even if
things like the Event Log are still missing. So I call that a decent
lunch hour's work :-)
[originally from svn r3034]
clears, and also to temporarily push the primary screen contents
into the scrollback while the alternate screen is active and bring
it back afterwards.
[originally from svn r2910]
which have a strange idea of what data should be signed in a PK auth
request. This actually got in my way while doing serious things at
work! :-)
[originally from svn r2800]
opaque to all platform-independent modules and only handled within
per-platform code. `Filename' is there because the Mac has a magic
way to store filenames (though currently this checkin doesn't
support it!); `FontSpec' is there so that all the auxiliary stuff
such as font height and charset and so on which is needed under
Windows but not Unix can be kept where it belongs, and so that I can
have a hope in hell of dealing with a font chooser in the forthcoming
cross-platform config box code, and best of all it gets the horrid
font height wart out of settings.c and into the Windows code where
it should be.
The Mac part of this checkin is a bunch of random guesses which will
probably not quite compile, but which look roughly right to me.
Sorry if I screwed it up, Ben :-)
[originally from svn r2765]
combining adjacent ones for the same region, and runs them all in do_paint.
I'm not sure it's entirely right, but it works on my Mac in every case I've
tested.
[originally from svn r2763]
foreground colours, and ESC[100m through ESC[107m to set bright
background colours. Hence, so do we. Bright-foreground is
distinguishable from bold, and bright-background distinguishable
from blink, when it leaves terminal.c; the front end may then choose
to display them in the same way if it's configured to do so. This
change makes the xterm backend for Turbo Vision (!!!) work properly.
Untested on Mac.
[originally from svn r2734]
Everything in there which is integral is now an actual int, which
means my forthcoming revamp of the config box will be able to work
with `int *' pointers without fear of doom.
[originally from svn r2733]
yet -- there's no Alt+keypad support, and no way for the front-end to find
out what it should do with the Num Lock light. It's also not fully tested.
Nonetheless, it's at least as good as the previous Mac keyboard handler.
Other platforms probably shouldn't adopt it just yet.
[originally from svn r2728]
both the raw and the cooked mouse button, with the mapping being done in
advance by the front-end. This is useful because it allows the front-end to
use information other than the raw button (e.g. the modifier state) to decide
which cooked button to generate.
.
Front ends other than the Mac one are untested, but they just call
translate_button() themselves and pass the result to term_mouse().
[originally from svn r2721]
areas of the code. Not all back-ends have been tested, but Telnet and SSH
behave reasonably.
Incidentally, almost all of this patch was written through Mac PuTTY,
admittedly over a Telnet connection.
[originally from svn r2615]
link-module const variable `be_default_protocol' which suggests a sensible
default to the front end (which can ignore it). (DEFAULT_PORT is replaced by a
lookup in the backend[] table.)
Still not pretty, but it does mean that the recent fix for `ssh-default'
doesn't break PuTTYtel.
[originally from svn r2613]
holdout static I hadn't noticed; unicode.c had one too; and a large
number of statics that were perfectly OK due to being constants have
been made `const', with assorted `const' repercussions all over the
place. I now declare `remove-statics' to be fixed.
[originally from svn r2594]
just done this the very simple way - bundle all the globals into a
data structure and pass pointers around. One particularly ugly wart
is that wc_to_mb now takes a pointer to this structure as an
argument (optional, may be NULL, and unused in any Unicode layer
that's even marginally less of a mess than the Windows one). I do
need to do this properly at some point, but for now this should just
about be adequate. As usual, the Mac port has not been updated.
[originally from svn r2592]
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]
and term_reconfig() now passes in a new structure which is copied
over the top. This means that the old and new structures can be
compared, and the _current_ as well as default states of auto wrap
mode, DEC origin mode, BCE, blinking text and character classes can
be conveniently reconfigured in mid-session without requiring a
terminal reset.
[originally from svn r2557]
the remote IP/port data provided by the server for forwarded
connections. Disabled by default, since it's incompatible with SSH2,
probably incompatible with some X clients, and tickles a bug in
at least one version of OpenSSH.
[originally from svn r2554]
we're going to be a security program, we can at least make a token
effort to use the most secure local X auth available! And I'm still
half-tempted to see if I can support it for remote X servers too...
[originally from svn r2537]
Windows and Mac backends have acquired auth-finding functions which
do nothing; Unix backend has acquired one which actually works, so
Plink can now do X forwarding believably.
(This checkin stretches into some unlikely parts of the code because
there have been one or two knock-on effects involving `const'. Bah.)
[originally from svn r2536]
and pterm need at least one default setting to be _different_ (pterm
needs the default term type to be `xterm', while plink needs it to
be taken from $TERM). So here's a completely new alternative
mechanism for platform- and app-specific default settings. Ben will
probably want to check the integrity of the Mac port, since I've
fiddled with it without testing that it still compiles.
[originally from svn r2513]
right-hand half of a CJK wide character; correct handling of cut and
paste when CJK text wraps between lines _irrespective of the parity
of the starting column_; correct handling of wordness values
irrespective of which half of a CJK character the user
double-clicked on; correct handling when any terminal activity
overwrites only one half of a CJK wide character. I think we now
behave marginally better than xterm in this respect (it has a redraw
problem when you overwrite the RH half of a CJK char), so I'm happy.
Also redefined the internal UCSWIDE marker to something in the
surrogate range, while I'm here, so that U+303F is available for use
by actual users.
[originally from svn r2426]
know what that encoding actually is, we can do our best to support
additional charsets (VT100 linedrawing, SCO ACS, UTF-8 mode) using
the available characters; if we don't, we fall back to a mode where
we disable all Unicode cut-and-paste and assume any Unicode
character is undisplayable.
[originally from svn r2413]
open an existing saved session. This has entailed adding an extra hook to
settings.c to allow for loading settings other than by name.
[originally from svn r2387]
SockAddr, which just contains an unresolved hostname and is created
by a stub function in *net.c. It's an error to pass this to most of
the real-meat functions in *net.c; these fake addresses should have
been dealt with by the time they get down that far. proxy.c now
contains name_lookup(), a wrapper on sk_namelookup() which decides
whether or not to do real DNS, and the individual proxy
implementations each deal sensibly with being handed an unresolved
address and avoid ever passing one down to *net.c.
[originally from svn r2353]
the benefit of X font names which are rather more verbose than
Windows. One day I want to replace all these fixed-size buffers with
sensible dynamically allocated stuff, but not today.
[originally from svn r2260]
This introduces a new front-end function, do_scroll(), which is expected to
scroll a part of the physical display and cause repaint events for any
areas that couldn't be scrolled (e.g. because they were hidden).
scroll_display() is a wrapper around this which also updates disptext to
match.
Currently, scroll_display is only used in response to user scrollback requests
(via term_scroll()), but extending scroll() to use it as well should be
easy.
All of this is conditional on the front end's defining OPTIMISE_SCROLL, since
only the Mac front end currently implements do_scroll().
[originally from svn r2242]
This doesn't include any mkfiles.pl glue, and is missing one or two other
fixes. The terminal emulator is kind of working, though, as, I believe, is
the store module. Everything else is yet to be done.
[originally from svn r2226]
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]
lpage_send out into the line discipline, making them _clients_ of
the Unicode layer rather than part of it. This means they can access
ldisc->term, which in turn means I've been able to remove the
temporary global variable `term'. We're slowly getting there.
[originally from svn r2143]
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]
terminal.c was apparently relying on implicit initialisation to
zero, and also I've removed the backends' dependency on terminal.h
by having terminal sizes explicitly passed in to back->size().
[originally from svn r2117]
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]
it's automatically deactivated by any keypress, so that command-line
beeps from (e.g.) filename completion don't suddenly stop occurring,
but it still provides a rapid response to an accidental spewing of a
binary to your terminal.
[originally from svn r2107]
login shell or not. Also moved these new pieces of configuration
into the Config structure, though they won't stay there forever
since they will need to be moved out into platform-dependent config.
[originally from svn r2060]
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]
beginning of a Unix port. It's nowhere near done, and currently it
won't even compile on Unix. But this represents the start of the
process of separating out platform-specific code, and also contains
the mkfiles.pl changes required to support a Unix makefile and a
non-flat source tree.
[originally from svn r1993]
Bump username storage from 32 to 100 chars. Also replaced a couple of magic
numbers with sizeof in ssh.c.
I don't believe this is going to startle any of the protocols PuTTY talks.
[originally from svn r1952]
