I've shifted away from using the SVN revision number as a monotonic
version identifier (replacing it in the Windows version resource with
a count of days since an arbitrary epoch), and I've removed all uses
of SVN keyword expansion (replacing them with version information
written out by Buildscr).
While I'm at it, I've done a major rewrite of the affected code which
centralises all the computation of the assorted version numbers and
strings into Buildscr, so that they're all more or less alongside each
other rather than scattered across multiple source files.
I've also retired the MD5-based manifest file system. A long time ago,
it seemed like a good idea to arrange that binaries of PuTTY would
automatically cease to identify themselves as a particular upstream
version number if any changes were made to the source code, so that if
someone made a local tweak and distributed the result then I wouldn't
get blamed for the results. Since then I've decided the whole idea is
more trouble than it's worth, so now distribution tarballs will have
version information baked in and people can just cope with that.
[originally from svn r10262]
The winegcc hack I use for my Coverity builds is currently using a
version of wincrypt.h that's missing a couple of constants I use.
Ensure they're defined by hand, but (just in case I defined them
_wrong_) also provide a command-line define so I can do that only in
the case of Coverity builds.
[originally from svn r10234]
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]
A user points out that the person who writes a REG_SZ into the
registry can choose whether or not to NUL-terminate it properly, and
if they don't, RegQueryValueEx will retrieve it without the NUL. So if
someone does that to PuTTY's saved session data, then PuTTY may
retrieve nonsense strings.
Arguably this is the fault of whoever tampered with the saved session
data without doing it the same way we would have, but even so, there
ought to be some handling at our end other than silently returning the
wrong data, and putting the NUL back on seems more sensible than
complaining loudly.
[originally from svn r10215]
The IDM_RECONF handler unconditionally calls ldisc_configure to
reconfigure the line discipline for the new echo/edit settings, but in
fact ldisc can be NULL if no session is currently active. (Indeed, the
very next line acknowledges this, by testing it for NULL before
calling ldisc_send!) Thanks to Alexander Wong for the report.
[originally from svn r10214]
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]
Philippe Maupertuis reports that on one particular machine, Windows
causes the named pipe created by upstream PuTTY to be owned by the
Administrators group SID rather than the user's SID, which defeats the
security check in the downstream PuTTY. No other machine has been
reported to do this, but nonetheless it's clearly a thing that can
sometimes happen, so we now work around it by specifying explicitly in
the security descriptor for the pipe that its owner should be the user
SID rather than any other SID we might have the right to use.
[originally from svn r10188]
winshare.c includes ssh.h, but if you defined NO_SECURITY it then
decides to fall back to including the stub noshare.c, which includes
ssh.h again. Fix by moving a block of includes inside the ifdef.
[originally from svn r10184]
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]
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]
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]
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 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]
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 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 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]
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]
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]
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]
It was one of those things that went in ages ago on Windows and never
got replicated in the Unix front end. And it needn't be: ldisc.c is a
perfect place to put it, since it knows which of the data it's sending
is based on a keystroke and which is automatically generated, and it
also has access to the terminal context. So now a keypress can
interrupt a runaway paste on all platforms.
[originally from svn r10025]
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 setting a must_close_session flag and having special code
in the message loop to check it, we'll schedule the call to
close_session using the new top-level callback system.
[originally from svn r10021]
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]
PuTTY does not trim a colon suffix off the hostname if it contains
_more than one_ colon. This allows IPv6 literals to be entered.
(Really we need to do a much bigger revamp of all uses of hostnames to
arrange that square-bracketed IPv6 literals work consistently, but
this at least removes a regression over 0.62.)
[originally from svn r9983]
[r9214 == a1f3b7a358]
palette_set() to be bogus. Fortunately, this isn't exploitable through
the terminal emulator, because the palette escape sequence parser
contains its own bounds check before even calling palette_set().
While I'm at it, fix the same goof in the OS X version! That port is
more or less abandoned, but that's no excuse for leaving obviously
wrong code lying around.
[originally from svn r9965]
support: transform_jumplist_registry should give its caller
dynamically allocated data if and only if it returns JUMPLISTREG_OK,
and get_jumplist_registry_entries should test the return value against
JUMPLISTREG_OK rather than a value from a totally different enum.
[originally from svn r9960]
The most interesting one is printer_add_enum, which I've modified to
take a char ** rather than a char * so that it can both realloc its
input buffer _and_ return NULL to indicate error.
[originally from svn r9959]
(This has also required me to add a currently unused nonfatal() to
PuTTYgen, since although PuTTYgen won't actually try to delete
putty.rnd, it does link in winstore.c as a whole.)
[originally from svn r9957]
strerror as I can arrange, wrapping up all the ugly FormatMessage
nonsense and caching previously looked-up messages for reuse so that
callers can treat them as static.
[originally from svn r9956]
ToAsciiEx, where possible.
This enables support for keys which generate Unicode characters that
aren't in the system code page, which seems to me like a perverse way
for Windows to have set up the system code page but apparently does
happen, e.g. (I'm told) U+0219 and U+021B on Romanian keyboards.
Patch mostly due to Andrei Damian-Fekete.
[originally from svn r9942]
gather extra entropy at Windows PuTTY startup time. (It's only used as
one of the inputs to PuTTY's internal entropy pool, so nobody is
required to trust it.)
[originally from svn r9941]
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]
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]
use 32-bit scrollbar position data instead of being limited to the
16-bit version that comes in scrollbar messages' wParam.
[originally from svn r9720]
capture the error code if listen() returned an error, and instead pass
0 (saved from the previous successful bind) to winsock_error_string.
[originally from svn r9708]
FormatMessage to get the OS's text for any error not in our own
translation table. Should eliminate the frustrating 'unknown error'.
(I haven't chosen to use FormatMessage unconditionally, because it
comes out with enormous messages along the lines of "No connection
could be made because the target machine actively refused it" in place
of "Connection refused" and I'm Unixy enough to prefer the latter.
Also, on older Windowses, Winsock error codes are in a separate API
segment and don't work with FormatMessage anyway.)
[originally from svn r9704]
IPv6 addresses, because I'd mistakenly cast an ai_addr to the low-
level 'struct in6_addr' instead of the correct 'struct sockaddr_in6'.
[originally from svn r9690]
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]
mistakenly rearranged the logic in an if statement in window.c, with
the effect that scroll-wheel events are no longer sent via xterm mouse
tracking. Put it back to the way it was.
[originally from svn r9679]
[r9214 == a1f3b7a358]
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]
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]
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]
sequence: since init_fonts sets up ucsdata based on the available
Windows fonts, we should call it before passing ucsdata to term_init.
[originally from svn r9527]
the offset horizontal line characters in the VT100 line-drawing set
(o,p,r,s), so that no trace of it - and hence no pointless performance
hit - is compiled into the cross-platform modules on non-Windows
platforms.
[originally from svn r9467]
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]
so we should ensure we treat it the same way as other WM_SIZEs that
show up during that time: set the width and height in conf, and set
the flag to have that width and height enacted on WM_EXITSIZEMOVE.
Fixes a bug in which dragging a PuTTY window directly from the Win7
snapped-to-half-screen position to the snapped-to-maximised state
would leave the terminal in the pre-snapped size.
[originally from svn r9404]
Pageant's IPC mechanism. It's incomplete (he sent a much more
comprehensive set of fixes that I haven't reviewed), but should be
adequate to mitigate a particular issue for Bazaar users.
[originally from svn r9355]
GUIs of Pageant and PuTTYgen. With that and the prompts_t redesign,
there should no longer be any limit on passphrase length other than
the patience of the user.
[originally from svn r9320]
