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]