One of my changes in uxnet.c was outside the NO_IPV6 ifdef, and broke
compilation in the normal mode. Revert all changes in that file and
replace with a reference to the 'step' parameter in the no-IPv6
version of the SOCKADDR_FAMILY macro, so that those warnings are
squelched anyway.
[originally from svn r10136]
[r10135 == e00a004e64]
A user pointed out that 'family' was uninitialised in config.c, and
when I tried test-building with -DNO_IPV6 (and the usual -Werror, of
course) some unused variables showed up in uxnet.c too.
[originally from svn r10135]
Both GUI PuTTY front ends have a piece of logic whereby a string is
interpreted as host:port if there's _one_ colon in it, but if there's
more than one colon then it's assumed to be an IPv6 literal with no
trailing port number. This permits the PuTTY command line to take
strings such as 'host', 'host:22' or '[::1]:22', but also cope with a
bare v6 literal such as '::1'.
This logic is also required in the two Plink front ends and in the
processing of CONF_loghost for host key indexing in ssh.c, but was
missing in all those places. Add it.
[originally from svn r10121]
I've gone through everywhere we handle host names / addresses (on
command lines, in PuTTY config, in port forwarding, in X display
names, in host key storage...) and tried to make them handle IPv6
literals sensibly, by using the host_str* functions I introduced in my
previous commit. Generally it's now OK to use a bracketed IPv6 literal
anywhere a hostname might have been valid; in a few cases where no
ambiguity exists (e.g. no :port suffix is permitted anyway)
unbracketed IPv6 literals are also acceptable.
[originally from svn r10120]
I found last week that when a local proxy process terminated
unexpectedly, Unix PuTTY went into a tight loop calling quit
functions, because if idle_toplevel_callback_func is called from
inside a subsidiary gtk_main then it will schedule a quit function and
_not_ disable itself, so that that quit function keeps being
rescheduled on subsequent calls.
To fix, I've tried to make the whole handling of idle and quit
functions more sensibly robust: we keep our own boolean flag
indicating whether each of our functions has already been scheduled
with GTK, and if so, we don't schedule the same one again. Also, when
idle_toplevel_callback_func schedules a quit function, it should
unschedule itself since it's now done everything it can until a
gtk_main instance quits.
[originally from svn r10100]
The one in Ubuntu 10.04 doesn't know what AM_PROG_AR means, so
configure.ac was broken in r10053 when fixing compatibility with later
versions; you can't win...
[originally from svn r10086]
[r10053 == 2d9cc79d53]
I've enabled gcc's format-string checking on dupprintf, by declaring
it in misc.h to have the appropriate GNU-specific attribute. This
pointed out a selection of warnings, which I've fixed.
[originally from svn r10084]
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]
It was only actually used in X11 and port forwarding, to find internal
state structures given only the Socket that ssh.c held. So now that
that lookup has been reworked to be the sensible way round,
private_ptr is no longer used for anything and can be removed.
[originally from svn r10075]
This prevents embarrassing mess-ups involving getting back a Socket
which has mostly been memset to 0 but contains an error message,
sk_close()ing it to free the memory, and finding that standard input
has been closed as a side effect.
[originally from svn r10073]
There are two new functions: one to construct a SockAddr wrapping a
Unix socket pathname (which can also be used as the destination for
new_connection), and one to establish a new listening Unix-domain
socket.
[originally from svn r10072]
The mechanism for constructing a new connection-type Socket when a
listening one receives an incoming connection previously worked by
passing a platform-specific 'OSSocket' type to the plug_accepting
function, which would then call sk_register to wrap it with a proper
Socket instance. This is less flexible than ideal, because it presumes
that only one kind of OS object might ever need to be turned into a
Socket. So I've replaced OSSocket throughout the code base with a pair
of parameters consisting of a function pointer and a context such that
passing the latter to the former returns the appropriate Socket; this
will permit different classes of listening Socket to pass different
function pointers.
In deference to the reality that OSSockets tend to be small integers
or pointer-sized OS handles, I've made the context parameter an
int/pointer union that can hold either of those directly, rather than
the usual approach of making it a plain 'void *' and requiring a
context structure to be dynamically allocated every time.
[originally from svn r10068]
Automake now insists that we run AM_PROG_AR if we're going to build a
library, and AM_PROG_CC_C_O if we're going to build anything with
extra compile options. Those extra macros seem harmless in previous
versions of automake.
[originally from svn r10053]
Unix GUI programs should not say 'Fatal Error' in the message box
title, and Plink should not destroy its logging context as a side
effect of printing a non-fatal error. Both appear to have been due to
inattentive cut and paste from the pre-existing fatal error functions.
[originally from svn r10044]
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]
Again, I've removed the special-purpose ad-hockery from the assorted
front end message loops that dealt with deferred handling of socket
errors, and instead uxnet.c and winnet.c arrange that for themselves
by calling the new general top-level callback mechanism.
[originally from svn r10023]
Instead of having a special GTK idle function for dealing with session
closing, I now use the new top-level callback mechanism which is
slightly simpler for calling a one-off function.
Also in this commit, I've arranged for connection_fatal to queue a
call to the same session close function after displaying the message
box, with the effect that now all the same processing takes place no
matter whether the session closes cleanly or uncleanly - e.g. the SSH
specials submenu is cleaned out, as it should be.
[originally from svn r10022]
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]
parallels a similar mechanism in winnet.c and came over by copy and
paste, but is pointless in the Unix networking API.
On Windows, if you're using a mechanism such as WSAAsyncSelect which
delivers readability notifications as messages rather than return
values from a system call, you only get notified that a socket is
readable once - it remembers that it's told you, and doesn't tell you
again until after you've done a read. So in the case where we
intentionally stop reading from a socket because our local buffer is
full, and later want to start reading again, we do a read from the
socket with MSG_PEEK set, and that clears Windows's flag and tells it
to start sending us readability notifications again.
On Unix, select() and friends didn't do anything so strange in the
first place, so the whole mechanism is unnecessary.
[originally from svn r9951]
immediately after conf_deserialise in the Duplicate Session receiver,
whereas I should have put it after the subsequent loop that extracts
the pty argv if any.
[originally from svn r9943]
[r9919 == ea301bdd9b]
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]
of the GET_32BIT macros and then used as length fields. Missing bounds
checks against zero have been added, and also I've introduced a helper
function toint() which casts from unsigned to int in such a way as to
avoid C undefined behaviour, since I'm not sure I trust compilers any
more to do the obviously sensible thing.
[originally from svn r9918]
code, which would have coped badly if ever asked to select the first
font in the list at a size smaller than it supported. Luckily the
first font tended to be one of the X numeric aliases (e.g. 10x20)
which was stored with size zero, so this probably didn't actually come
up for anyone, but better safe than sorry.
[originally from svn r9910]
segfaults if a PuTTY or pterm did not close on exit and then you
either typed something via input_method_commit_event or changed the
line editing or echo settings.
[originally from svn r9908]
where the GTK1 detection function AM_PATH_GTK hasn't been provided by
/usr/share/aclocal/gtk.m4 or equivalent.
(Systems without gtk.m4 are becoming more common, but on the other
hand I know at least one person is still using GTK 1 PuTTY since the
0.62 release.)
[originally from svn r9868]
character set configuration to UTF-8, on both Windows and Unix, and
reorganise the dropdown lists in the Translation menu so that UTF-8
appears at the top (and Unix's odd "use font encoding" is relegated to
the bottom of the list like the special-purpose oddity it is).
[originally from svn r9843]
privileges just before dying of a fatal signal. I'm not sure what I
intended it for in the first place; it certainly isn't doing its job
properly (no setgid), it's causing compiler warnings due to not
checking the setuid return code, and we can't think of any useful
purpose for it.
[originally from svn r9766]
and returns its error message as a string, instead of actually
printing it on standard error and exiting. Now we can preserve the
previous error behaviour when we get a nonexistent font name at
startup time, but no longer rudely terminate in mid-session if the
user configures a bogus font name in Change Settings.
[originally from svn r9745]
pty_utmp_helper_pipe _and_ the close of it if we're not going to write
should be conditionalised on the pipe existing, rather than just the
former!
[originally from svn r9729]
open("/dev/ptmx"), where the former is available. Improves
portability, since at least one OS (OpenBSD) supports the POSIX pty
functions but does it via an underlying mechanism which doesn't
involving having a /dev/ptmx.
[originally from svn r9728]
OS doesn't automatically assume it.
(It would seem faintly weird to me - surely opening the master end of
a given pty is a fairly good indication that you're _not_ a process
running inside it which wants to have it available as /dev/tty! But
you never know...)
[originally from svn r9727]
localhost connections, and also enable X forwarding in such a way that
it will attempt to connect to a Unix-domain X server socket, an
assertion will fail when proxy_for_destination() tries to call
sk_getaddr(). Fix by ensuring that Unix-domain sockets are _never_
proxied, since they fundamentally can't be.
[originally from svn r9688]
Well, at least across all command-line tools on both Windows and Unix,
and the GTK apps on Unix too. The Windows GUI apps fundamentally can't
write to standard output and it doesn't seem sensible to use message
boxes for these purposes :-)
[originally from svn r9673]
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]
Unconditionally override the configured terminal size with the one
from stdin if it's available. This avoids the silliness whereby if
Default Settings had a terminal size set, Plink used this and thus
caused the server to use the wrong size.
[originally from svn r9624]
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]
having just noticed that Makefile.gtk had it and this one doesn't. (Of
course, this being autoconf, we can easily enough make it conditional
on the compiler actually being gcc.)
[originally from svn r9583]
and the argument list contains only one string, try again by passing
that single string to "$SHELL -c" to be parsed as a shell command.
This matches xterm's behaviour (as of xterm 261, at least), and means
in practice that users can do _either_ of 'pterm -e some command' and
'pterm -e "some command"'.
(A quick survey suggests that the majority of X terminal programs agree
with pterm's old behaviour of only supporting '-e some command',
except that gnome-terminal only supports the other behaviour and xterm
supports both. With that disagreement, I think supporting both is
probably the sensible thing.)
[originally from svn r9575]
piece of keyboard handling: if Num Lock is on, numeric keypad keys are
eaten by the IM, so we must avoid passing them to the IM in the first
place if we're in any non-default numeric keypad mode (application or
Nethack).
This is a grubby way to do it, but the more obvious approach of just
moving the Nethack and app-keypad if statements up to above the IM
call doesn't work because those statements depend on the generic
Alt-prefix handling that happens just _below_ the IM call. So instead
I just repeat the list of keystrokes and modes in an if statement
conditionalising the IM call.
[originally from svn r9573]
[r9567 == 7fc8db15b2]
a GtkIMMulticontext and having that filter most keypresses. I think
I've got this right so that it doesn't break any previous deliberate
keyboard-handling behaviour that's now _after_ the 'if (filter
keypress) return' statement.
[originally from svn r9567]
The previous platform-dependent ifdefs, switching between a system
which tried to cope with spurious callbacks (which I'd observed on
Windows) and one which tried to cope with system clock jumps (which
can happen on Unix, if you use gettimeofday) have been completely
removed, and replaced with a much simpler approach which just copes
with system clock jumps by triggering any timers immediately.
None of the resulting effects should be catastrophic (the worst thing
might be the waste of CPU in a spurious rekey, but as long as the
system clock isn't jumping around _all_ the time that's hardly
critical) and in any case the Unix port has had a long-standing oddity
involving occasional lockups if pterm or PuTTY runs for too long,
which hopefully this should replace with a much less bad failure mode.
And the code is much simpler, which is not to be sneezed at.
[originally from svn r9528]
will not even initialise sbstring[0], so we shouldn't even look at it
let alone depend on it to tell us the desired character was absent.
[originally from svn r9465]
logevent(), which temporarily turn off the raw mode we've put stderr
into, so that they don't get called if the log_eventlog() call between
them is not _actually_ going to write to stderr.
Fixes a bug in which, if you define a Unix PuTTY saved session which
uses 'plink -nc' as a local proxy command and then run PuTTY
backgrounded from the shell with that session loaded, the subprocess
Plink would get SIGTTOU when it tried to muck about with stderr and
the whole thing would grind to a halt. I'm prepared to consider that
acceptable if Plink _really_ wants to write on standard error, but if
it doesn't, it should just carry on working in the background!
[originally from svn r9462]
duplicate the strings they pass to gtk_entry_set_text. I was already
doing that in dlg_editbox_set, but forgot to add the same code when I
revamped FontSpec and Filename to contain dynamically allocated
strings (r9314 and r9316 respectively). This fixes a bug where, on
some versions of GTK (but apparently not up-to-date versions), loading
a saved session causes gibberish to appear in file-selector edit boxes
accompanied by a valgrind error.
[originally from svn r9456]
[r9314 == 9c75fe9a3f]
[r9316 == 62cbc7dc0b]
deprecated g_strcasecmp (since all the strings being compared are
parts of XLFDs and won't be in interesting character sets anyway).
[originally from svn r9376]
remembered to do before! Also some related fixes, such as that after
we do so we should immediately stop selecting on the socket in
question.
[originally from svn r9363]
of local sockets and pipes all open at once, and if one of them is
uncleanly closed from the remote end we don't want the whole
application to die - we want to close that socket's SSH channel and
continue with the rest of the run.
[originally from svn r9359]
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]
because (a) under that circumstance we won't be writing to utmp
anyway, and (b) if we aren't setuid, then we won't have created the
pty at the point we fork, so even if our subprocess _could_ have
written to utmp it wouldn't have done it right!
Spotted by valgrind (triggering on the access beyond the end of the
ttyname string in setup_utmp, clueing me in to it having been empty).
[originally from svn r9309]
hadn't previously noticed, but Pango was helpfully re-reversing text
that PuTTY's own bidi module had already reversed, leading to Arabic
text being wrongly displayed and also total chaos when you move the
cursor over it or try to cut and paste it.
[originally from svn r9294]
by introducing a wrapper around an individual unifont which falls back
to Pango (which already has built-in fallback) in the case where the
selected font doesn't support the glyph in question.
The wrapper itself is a (vestigial) subclass of unifont, to minimise
disturbance at the call sites.
[originally from svn r9293]
individual font implementation as wchar_t, rather than having to be
converted by the client into the appropriate MBCS/SBCS.
This also means I can remove 'real_charset' from the public-facing
contents of the unifont structure.
[originally from svn r9292]
font operations are now done directly using Xlib calls, and the only
interaction with GDK within the x11font mechanism is to get the X ids
for drawables, GCs and the X display itself.
This should remove an obstacle to porting to GTK3, and also makes the
XFontStruct for loaded fonts more readily available, which I hope will
come in handy for another plan I have in mind.
[originally from svn r9289]
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]
of preference so that the later ones overwrite the configured stuff
from the older ones, test in decreasing order of preference and stop
as soon as one is successful. Fixes a problem in which
autoconfiguration on a system containing only GTK 1 would go wrong
because the _failed_ test for GTK 2 would overwrite some but not all
of the variables set by the successful test for v1.
[originally from svn r9270]
error, we should also read the corresponding password inputs from
/dev/tty. That way, redirection of Plink's standard input will play
nicely with SSH sessions that need interactive login.
(This is what we get for disdaining getpass(3) and going it alone, of
course. But we had no choice, due to the extra output part way through
keyboard-interactive.)
[originally from svn r9262]
I think I have to consider this to be a separate but related change to
the wishlist item 'pscp-filemodes'; that was written before the Unix
port existed, and referred to the ability to configure the permissions
used for files copied from Windows to Unix - which is still not done.
[originally from svn r9260]
--without-gtk as a means of manually overriding the makefile into one
building the command-line tools only (as it would if GTK were not
found at all at configure time).
[originally from svn r9240]
mkfiles.pl no longer generates a Makefile.in, but instead generates a
Makefile.am on which mkauto.sh runs automake. This means that the
autoconfigured makefile now does build-time dependency tracking (a
standard feature of automake-generated makefiles), and is generally
more like what Unix people will expect.
Some of the old-style make command-line settings (VER=-DRELEASE=foo,
XFLAGS=-DDEBUG) will still work; the COMPAT settings are better done
by autoconfiguration, and my habitual 'XFLAGS="-g -O0"' for an easily
debuggable build will actually not work any more because CFLAGS is
specified _after_ XFLAGS, so I should instead write 'make CFLAGS=-O0'
(-g is the default in automake, removed at 'make install' time).
The new makefile will automatically degrade into one that builds the
command-line tools only, in the case where GTK could not be found. In
principle, therefore, it should be an adequate replacement for _both_
the static Unix makefiles, Makefile.gtk and Makefile.ux. I haven't
actually retired those in this commit, but I'm pretty tempted.
[originally from svn r9239]
on success rather than to $LIBS, because it's only used in the GUI
tools and we don't want the command-line tools linked against it.
[originally from svn r9238]
which GTK version you want to build with if both are installed. Based
on a patch by Malcolm Smith, though somewhat modified.
[originally from svn r9228]
