It's an old prototype from part way through the development of
connection sharing, which I must have forgotten to fix because by the
time I changed the prototype no platform was using noshare.c any more.
[originally from svn r10183]
Timer objects evaporate when our timer_trigger callback is called, and
therefore we should not remember their ids beyond that time and
attempt to cancel them later. Previous versions of GTK silently
ignored us doing that, but upgrading to Ubuntu Trusty has given me a
version of GTK that complains about it, so let's stop doing it.
[originally from svn r10181]
Martin Prikryl reports that it had the exact same bug as old OpenSSH
(insisting that RSA signature integers be padded with leading zero
bytes to the same length as the RSA modulus, where in fact RFC 4253
section 6.6 says it ought to have _no_ padding), but is recently
fixed. The first version string to not have the bug is reported to be
"mod_sftp/0.9.9", so here we recognise everything less than that as
requiring our existing workaround.
[originally from svn r10161]
questionnaires in unfriendly formats like Excel, apparently in the
mistaken belief that we have some kind of incentive to answer them. I
hope I've managed to identify the key reason why they make this
mistake.
[originally from svn r10156]
It was intended to ensure that people still working with DOS filename
restrictions (or things approximating that, e.g. VFAT) wouldn't have
trouble. Those days are surely long gone, and now zip -k is causing
its own trouble with the new VS2010/VS2012 project files, which
include pairs of filenames that become the same under the zip -k
transformation and hence break the source archive build.
[originally from svn r10155]
Its previous policy of silence made sense before we did builds using
bob (gratuitous output on success caused cronmail) but now it just
makes it hard to spot problems.
[originally from svn r10153]
We were inventing a random number by starting with a long zero bignum
and then setting bits at random, which left an opportunity for the
result to be a non-normalised representation (with a leading zero
word) and hence fail an assertion in bignum_cmp.
[originally from svn r10147]
gcc 4.8 compiling with -O3 gives a new warning about the access to
st->pending at the top of lz77_compress, because for some reason it
thinks there's an out-of-bounds array access there (or perhaps just a
potential one, I'm not really sure which side -Warray-bounds is erring
on). Add an assertion reassuring it that st->npending can't get bigger
than the size of st->pending at the site it's complaining about, and a
second one at the site where st->npending is increased (just in case
my analysis of why it can't happen was wrong!). Also add a comment
explaining the assertions.
[originally from svn r10144]
This rearranges the object files so that they each live alongside
their original source file, instead of all being in the same
directory. To my way of thinking this is a more or less neutral change
(perhaps marginally less tidy), but autotools is apparently beginning
to think it's the One True Way and 1.14 will give a warning if you
don't have it enabled.
[originally from svn r10142]
Previously, 'configure' and its assorted machinery lived in the 'unix'
subdir, because that seemed like a clean place to keep it given that
all the other per-platform Makefiles live in their platform
directories. However, this never sat all that happily with autotools,
and even less so now that it likes to have object file pathnames
parallel source file pathnames: if you have Makefile.am refer to
source files outside its subdir as "../terminal.c" and enable
subdir-objects then any out-of-tree build calls the corresponding
object file "../terminal.o" and so your build products mostly end up
at the directory above your build dir! And as of autotools 1.14 my
previous compensatory bodge of prefixing every source file path in
Makefile.am with "$(srcdir)" has stopped working too.
So I'm giving in to necessity, and changing policy by moving the
configure machinery up to the top level of the source tree where
autotools will be less confused by it. This should not be taken as any
indication of the primacy of the Unix port, only of the recalcitrance
of autotools.
Whereas before we had a trivial script called 'configure' at the top
level that invoked unix/configure to effectively do an 'out-of-tree
build' (for make purposes) at the top level of the source tree, we now
have a similar script in unix/configure. So this _should_ make very
little difference: people who were previously running configure from
the top level should still be able to, and likewise people who were
running it from the unix subdir.
[originally from svn r10141]
I had somehow missed this completely out of the GTK mouse-button
handling and never noticed until now!
Of course, like any other mouse action, if you want it to be handled
locally rather than passed through then you can hold down Shift.
[originally from svn r10139]
On Windows (X mouse reporting of the mouse wheel isn't currently done
by the Unix front end, though I'm shortly about to fix that too) a
mouse wheel event is translated into a virtual button, and we send
both a press and a release of that button to terminal.c, which encodes
both in X mouse reporting escape sequences and passes them on to the
server. This isn't consistent with what xterm does - scroll-wheel
events are encoded _like_ button presses, but differ semantically in
that they don't have matching releases. So we're updating to match
xterm.
[originally from svn r10138]
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]
Handlers for a number of escape sequences, notably including ESC[J and
the sequences that switch to/from the alternate screen, were
unconditionally resetting the scrollback instead of first checking the
'Reset scrollback on display activity' configuration option. I've
added the missing if statements, so now 'Reset scrollback on display
activity' should actually mean what it says.
For example, this would have inconvenienced an mplayer user, who
wouldn't be able to go up and check their scrollback while mplayer was
repeatedly redisplaying its status line, because mplayer uses ESC[J to
erase each version of the status line before printing the next
version.
[originally from svn r10125]
If we search for a colon by computing ptr + host_strcspn(ptr,":"),
then the resulting pointer is always non-NULL, and the 'not found'
condition is not !p but !*p.
This typo could have caused PuTTY to overrun a string, but not in a
security-bug sense because any such string would have to have been
loaded from the configuration rather than received from a hostile
source.
[originally from svn r10123]
There's been a long-standing FIXME in Windows's sk_newlistener which
says that in IPv6 mode, an explicit source address (e.g. from a
command-line option of the form -L srcaddr:12345:dest:22) is ignored.
Now it's honoured if possible.
[originally from svn r10122]
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]
These are intended to make it easier to handle strings of the form
"hostname:port" or other colon-separated things including hostnames
(such as the -L and -R command-line option arguments), even though the
hostname part might be a square-bracketed IPv6 address literal
containing colons that have to _not_ be treated as separating the
top-level string components.
Three of these functions have semantics as much like existing C
library functions as I could make them (host_strchr, host_strrchr,
host_strcspn) so that it wouldn't be too error-prone to replace
existing C functions with them at lots of call sites. The fourth
function (host_strduptrim) just strips square brackets off anything
that looks like an IPv6 literal.
[originally from svn r10119]
The assertions I added to sshrand.c in r9930 are now justified,
because they were failing when cmdgen was used to convert a key into
either foreign private key file format - both the export functions
require random_byte() for one reason or another, and random_ref()
hadn't been called first.
[originally from svn r10117]
[r9930 == 33f485c1c3]
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]
Simon Tatham
Jacob Nevins