Thanks to Mike Edenfield for the initial version of this patch; I've
polished it up a bit (in particular inventing a more overengineered
GUID generation strategy) but most of it is his.
[originally from svn r10112]
Mike Edenfield points out that modern versions of the Windows SDK have
decided that 'INPUT' is a sensible name for an OS data structure
(sigh), and provided a patch to add a disambiguating prefix to
winhandl.c's enum values INPUT, OUTPUT and FOREIGN.
[originally from svn r10109]
The line that resets st->pktin->length to cover only the semantic
payload of the SSH message was overwriting the modification to
st->pktin->length performed by the optional decompression step. I
didn't notice because I don't habitually enable compression.
[originally from svn r10103]
[r10070 == 9f5d51a4ac]
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]
Previously I had unthinkingly called the general-purpose
check_selection() routine to indicate that I was going to mess with n
character cells right of the cursor position, causing the selection
highlight to be removed if it intersected that region. This is all
wrong, since actually the whole region from cursor to EOL is modified
by any character insertion or deletion, so if we were going to call
check_selection it should be on that whole region. (Quick demo: select
part of the line to the right of the cursor, then emit ESC[P or ESC[@
and see the text move left or right while the highlight stays put.)
So we could just call check_selection() on that larger affected
region, and that would be correct. However, we can do something
slightly more elegant in the case where the selection is contained
entirely within the subregion that moves to one side (as opposed to
the characters that actually vanish at one or other end): we can move
the selection highlight with the text under it, to preserve the visual
reminder of which text was selected for as long as possible.
[originally from svn r10097]
Daniel Meidlinger reports that at least one Windows machine which is
not obviously otherwise misconfigured will respond to our
SetEntriesInAcl call with odd errors like ERROR_NONE_MAPPED or
ERROR_TRUSTED_RELATIONSHIP_FAILURE. This is apparently to do with
failure to convert the names "EVERYONE" and "CURRENT_USER" used in the
ACL specification to SIDs. (Or perhaps only one of them is the problem
- I didn't investigate in that direction.)
If we instead construct a fully SID-based ACL, using the well-known
world SID in place of EVERYONE and calling our existing get_user_sid
routine in place of CURRENT_USER, he reports that the problem goes
away, so let's do that instead.
While I'm here, I've slightly simplified the function prototype of
make_private_security_descriptor(), by turning 'networksid' into an
internal static that we can reuse in subsequent calls once we've set
it up. (Mostly because I didn't fancy adding another two pointless
parameters at every call site for the two new SIDs.)
[originally from svn r10096]
This will be useful if someone gets a mysterious Windows error on a
system configured into a language we don't speak - if they cut and
paste the error message to send to us, then we won't have to try to
translate it.
[originally from svn r10092]
XP doesn't have it, and I think having connection sharing work without
its privacy enhancement is better than having it not work at all.
[originally from svn r10087]
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]
There's now a winsecur.[ch], which centralises helper functions using
the Windows security stuff in advapi.h (currently just get_user_sid),
and also centralises the run-time loading of those functions and
checking they're all there.
[originally from svn r10082]
Now that it doesn't actually make a network connection because that's
deferred until after the X authorisation exchange, there's no point in
having it return an error message and write the real output through a
pointer argument. Instead, we can just have it return xconn directly
and simplify the call sites.
[originally from svn r10081]
I've moved it out into a separate function, preparatory to calling it
from somewhere completely different in changes to come. Also, we now
retain the peer address sent from the SSH server in string form,
rather than translating it immediately into a numeric IP address, so
that its original form will be available later to pass on elsewhere.
[originally from svn r10080]
Rather than the top-level component of X forwarding being an
X11Display structure which owns some auth data, it's now a collection
of X11FakeAuth structures, each of which owns a display. The idea is
that when we receive an X connection, we wait to see which of our
available auth cookies it matches, and then connect to whatever X
display that auth cookie identifies. At present the tree will only
have one thing in it; this is all groundwork for later changes.
[originally from svn r10079]
Now we wait to open the socket to the X server until we've seen the
authorisation data. This prepares us to do something else with the
channel if we see different auth data, which will come up in
connection sharing.
[originally from svn r10078]
I don't know that this can ever be triggered in the current state of
the code, but when I start mucking around with SSH session closing in
the near future, it may be handy to have it.
[originally from svn r10076]
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]
The most important change is that, where previously ssh.c held the
Socket pointer for each X11 and port forwarding, and the support
modules would find their internal state structure by calling
sk_get_private_ptr on that Socket, it's now the other way round. ssh.c
now directly holds the internal state structure pointer for each
forwarding, and when the support module needs the Socket it looks it
up in a field of that. This will come in handy when I decouple socket
creation from logical forwarding setup, so that X forwardings can
delay actually opening a connection to an X server until they look at
the authentication data and see which server it has to be.
However, while I'm here, I've also taken the opportunity to clean up a
few other points, notably error message handling, and also the fact
that the same kind of state structure was used for both
connection-type and listening-type port forwardings. Now there are
separate PortForwarding and PortListener structure types, which seems
far more sensible.
[originally from svn r10074]
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]
Because the upcoming connection sharing changes are going to involve
us emitting outgoing SSH packets into our log file that we didn't
construct ourselves, we can no longer rely on metadata inserted at
packet construction time to tell us which parts of which packets have
to be blanked or omitted in the SSH packet log. Instead, we now have
functions that deal with constructing the blanks array just before
passing all kinds of packet (both SSH-1 and SSH-2, incoming and
outgoing) to logging.c; the blanks/nblanks fields in struct Packet are
therefore no longer needed.
[originally from svn r10071]
There's always been some confusion over exactly what it all means. I
haven't cleaned it up to the point of complete sensibleness, but I've
got it to a point where I can at least understand and document the
remaining non-sensibleness.
[originally from svn r10070]
This commit adds two new support modules, winnpc.c and winnps.c, which
deal respectively with being a client and server of a Windows named
pipe (which, in spite of what Unix programmers will infer from that
name, is actually closer to Windows's analogue of a Unix-domain
socket). Each one provides a fully featured Socket wrapper around the
hairy Windows named pipe API, so that the rest of the code base should
be able to use these interchangeably with ordinary sockets and hardly
notice the difference.
As part of this work, I've introduced a mechanism in winhandl.c to
permit it to store handles of event objects on behalf of other Windows
support modules and deal with passing them to applications' main event
loops as necessary. (Perhaps it would have been cleaner to split
winhandl.c into an event-object tracking layer analogous to uxsel, and
the handle management which is winhandl.c's proper job, but this is
less disruptive for the present.)
[originally from svn r10069]
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]
That's been a FIXME in the code for ages, because it's difficult to
get winhandl.c to stop an already-started read from a handle (since
the read is a blocking system call running in a separate thread). But
I now realise it isn't absolutely necessary to do so - you can just
buffer one lot of data from winhandl and _then_ tell it to stop.
[originally from svn r10067]
It's now kept in a separate module, where it can be reused
conveniently for other kinds of Windows HANDLE that I want to wrap in
the PuTTY Socket abstraction - for example, the named pipes that I
shortly plan to use for the Windows side of connection-sharing IPC.
[originally from svn r10066]
This isn't yet used, but I plan to use it in situations where you have
to report errors by returning a valid Socket on which the client wlil
call sk_socket_error, but in fact you notice the error _before_
instantiating your usual kind of Socket. The resulting Socket is
usable for nothing except reading out the error string and closing it.
[originally from svn r10065]
It's now indexed by source hostname as well as source port (so that
separate requests for the server to listen on addr1:1234 and
addr2:1234 can be disambiguated), and also its destination host name
is dynamically allocated rather than a fixed-size buffer.
[originally from svn r10062]
This restores PuTTY's backward compatibility to versions of Windows
too old to have ToUnicodeEx in their system libraries, which was
accidentally broken in 0.63.
[originally from svn r10061]
A couple of users report that my recent reworking of the Windows
top-level message loop has led to messages occasionally being lost,
and MsgWaitForMultipleObjects blocking when it ought to have been
called with a zero timeout. I haven't been able to reproduce this
myself, but according to one reporter, PeekMessage(PM_NOREMOVE) is
effective at checking for a non-empty message queue in a way that
GetQueueStatus is not. Switch to using that instead. Thanks to Eric
Flumerfelt for debugging and testing help.
[originally from svn r10057]
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]
Jochen Erwied points out that once you've used PeekMessage to remove
_one_ message from the message queue, MsgWaitForMultipleObjects will
consider the whole queue to have been 'read', or at least looked at
and deemed uninteresting, and so it will block until a further message
comes in. Hence, my change in r10040 which stops us from looping on
PeekMessage until the queue is empty has the effect of causing the
rest of the message queue not to be acted on until a new message comes
in to unblock it. Fix by checking if the queue is nonempty in advance
of calling MsgWaitForMultipleObjects, and if so, giving it a zero
timeout just as we do if there's a pending toplevel callback.
[originally from svn r10052]
[r10040 == 5c4ce2fadf]
No current PuTTY utility was calling random_ref more than once per run
(ssh.c and the two main PuTTYgen programs call it once each), but if
one ever does (or if derived code does), it will want the reference
count to actually work sensibly.
[originally from svn r10049]
Martin Prikryl helpfully points out that when I revamped the socket
error mechanism using toplevel callbacks, I also accidentally passed
the error code to the wrong function. Use winsock_error_string instead.
[originally from svn r10048]
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]
I temporarily applied it as a means of testing the revised event loops
in r10040, and accidentally folded it into my final commit instead of
backing it out. Ahem.
[originally from svn r10042]
[r10040 == 5c4ce2fadf]
In r10020 I carefully reimplemented using timing.c and callback.c the
same policy for large pastes that the previous code appeared to be
implementing ad-hoc, which included a 450ms delay between sending
successive lines of pasted text if no visible acknowledgment of the
just-sent line (in the form of a \n or \r) came back from the
application.
However, it turns out that that *wasn't* what the old code was doing.
It *would* have done that, but for the bug that it never actually set
the 'last_paste' variable, and never has done since it was first
introduced way back in r516! So the policy I thought had been in force
forever has in fact only been in force since I unwittingly fixed that
bug in r10020 - and it turns out to be a bad idea, breaking pastes
into vi in particular.
So I've removed the timed paste code completely, on the basis that
it's never actually worked and nobody seems to have been unhappy about
that. Now we still break large pastes into separate lines and send
them in successive top-level callbacks, and the user can still press a
key to interrupt a paste if they manage to catch it still going on,
but there's no attempted *delay* any more.
(It's possible that what I *really* ought to be doing is calling
back->sendbuffer() to see whether the backend is consuming the data
pasted so far, and if not, deferring the rest of the paste until the
send buffer becomes smaller. Then we could have pasting be delayed by
back-pressure from the recipient, and still manually interruptible
during that delay, but not have it delayed by anything else. But what
we have here should at least manage to be equivalent to the *actual*
rather than the intended old policy.)
[originally from svn r10041]
[r516 == 0d5d39064a]
[r10020 == 7be9af74ec]
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]
Anthony Ho reports that this can occur naturally in some situation
involving Windows 8 + IE 11 and dynamic port forwarding: apparently we
get through the SOCKS negotiation, send our CHANNEL_OPEN, and then
*immediately* suffer a local WSAECONNABORTED error before the server
has sent back its OPEN_CONFIRMATION or OPEN_FAILURE. In this situation
ssh2_channel_check_close was failing to notice that the channel didn't
yet have a valid server id, and sending out a CHANNEL_CLOSE anyway
containing 32 bits of uninitialised nonsense.
We now handle this by turning our half-open CHAN_SOCKDATA_DORMANT into
a half-open CHAN_ZOMBIE, which means in turn that our handler
functions for OPEN_CONFIRMATION and OPEN_FAILURE have to recognise and
handle that case, the former by immediately initiating channel closure
once we _do_ have the channel's server id to do it with.
[originally from svn r10039]
