It's a function that exists on all platforms, not just on Unix - it's
used in ldisc.c - so it shouldn't have been declared only in unix.h.
Score another for clang's warnings.
I was having a play with clang's MSVC compatibility mode, just to see
how much of PuTTY it could compile, and one of its warnings pointed
out this error which must have crept in when I was changing the EOF
flags in winhandl.c from booleans to three-state enums - I left the !
on the front of what was previously an if (!thing) and needed to turn
into if (thing == EOF_NO).
Several functions were passing a 'char *error' and assigning error
messages directly into 'error', where they should have been passing
'char **error' and assigning error messages into '*error' if the error
message is to be returned to the caller. This would have led to
incomplete error messages.
Mostly so that we don't have to malloc contiguous space for them
inside PuTTY; since we've already got a handy constant saying how big
is too big, we might as well use it to sanity-check the contents of
our agent forwarding channels.
As documented in bug 'win-process-acl-finesse', we've had enough
assorted complaints about it breaking various non-malicious pieces of
Windows process interaction (ranging from git->plink integration to
screen readers for the vision-impaired) that I think it's more
sensible to set the process back to its default level of protection.
This precaution was never a fully effective protection anyway, due to
the race condition at process startup; the only properly effective
defence would have been to prevent malware running under the same user
ID as PuTTY in the first place, so in that sense, nothing has changed.
But people who want the arguable defence-in-depth advantage of the ACL
restriction can now turn it on with the '-restrict-acl' command-line
option, and it's up to them whether they can live with the assorted
inconveniences that come with it.
In the course of this change, I've centralised a bit more of the
restriction code into winsecur.c, to avoid repeating the error
handling in multiple places.
When we're going through the response from an SSH agent we asked for a
list of keys, and processing the string lengths in the SSH-2 sequence
of (public blob, comment) pairs, we were adding 4 to each string
length, and although we checked if the result came out to a negative
value (if interpreted as a signed integer) or a positive one going
beyond the end of the response buffer, we didn't check if it wrapped
round to a positive value less than 4. As a result, if an agent
returned malformed data sent a length field of 0xFFFFFFFC, the pointer
would advance no distance at all through the buffer, and the next
iteration of the loop would check the same length field again.
(However, this would only consume CPU pointlessly for a limited time,
because the outer loop up to 'nkeys' would still terminate sooner or
later. Also, I don't think this can sensibly be classed as a serious
security hazard - it's arguably a borderline DoS, but it requires a
hostile SSH _agent_ if data of that type is to be sent on purpose, and
an untrusted SSH agent is not part of the normal security model!)
The previous agent-forwarding system worked by passing each complete
query received from the input to agent_query() as soon as it was
ready. So if the remote client were to pipeline multiple requests,
then Unix PuTTY (in which agent_query() works asynchronously) would
parallelise them into many _simultaneous_ connections to the real
agent - and would not track which query went out first, so that if the
real agent happened to send its replies (to what _it_ thought were
independent clients) in the wrong order, then PuTTY would serialise
the replies on to the forwarding channel in whatever order it got
them, which wouldn't be the order the remote client was expecting.
To solve this, I've done a considerable rewrite, which keeps the
request stream in a bufchain, and only removes data from the bufchain
when it has a complete request. Then, if agent_query decides to be
asynchronous, the forwarding system waits for _that_ agent response
before even trying to extract the next request's worth of data from
the bufchain.
As an added bonus (in principle), this gives agent-forwarding channels
some actual flow control for the first time ever! If a client spams us
with an endless stream of rapid requests, and never reads its
responses, then the output side of the channel will run out of window,
which causes us to stop processing requests until we have space to
send responses again, which in turn causes us to stop granting extra
window on the input side, which serves the client right.
Now, instead of returning a boolean indicating whether the query has
completed or is still pending, agent_query() returns NULL to indicate
that the query _has_ completed, and if it hasn't, it returns a pointer
to a context structure representing the pending query, so that the
latter can be used to cancel the query if (for example) you later
decide you need to free the thing its callback was using as a context.
This should fix a potential race-condition segfault if you overload an
agent forwarding channel and then close it abruptly. (Which nobody
will be doing for sensible purposes, of course! But I ran across this
while stress-testing other aspects of agent forwarding.)
It's been commented out for ages because it never really worked, and
it's about to become further out of date when I make other changes to
the agent client code, so it's time to get rid of it before it gets in
the way.
If and when I do get round to supporting asynchronous agent requests
on Windows, it's now pretty clear to me that trying to coerce this
ghastly window-message IPC into the right shape is the wrong way, and
a better approach will be to make Pageant support a named-pipe based
alternative transport for its agent connections, and speaking the
ordinary stream-oriented agent protocol over that. Then Pageant will
be able to start adding interactive features (like confirmation
dialogs or on-demand decryption) with freedom to reply to multiple
simultaneous agent connections in whatever order it finds convenient.
In commit be586d53b I made empty.h depend on $(allsources), which
unfortunately was defined so as to include empty.h. This was harmless,
because make just ignored the circular dependency, but annoying,
because it constantly mentioned that it was ignoring it.
backend_socket_log was generating the IP address in its error messages
by means of calling sk_getaddr(). But sk_getaddr only gets a SockAddr,
which may contain a whole list of candidate addresses; it doesn't also
get the information stored in the 'step' field of the Socket that was
actually trying to make the connection, which says _which_ of those
addresses we were in the middle of trying to connect to.
So now we construct a temporary SockAddr that points at the
appropriate one of the addresses, and use that for calls to plug_log
during connection setup.
If connect() returns EINPROGRESS, then previously we would detect a
successful connection by the socket becoming selectable for writing,
and spot an unsuccessful one by an error code being returned on the
first attempt to read from it.
This isn't the right way to do it: the right way is to respond to the
initial writability notification by calling getsockopt(SO_ERROR) to
retrieve the error code (if any) from the completed connection
attempt. Doing it the old way had the problem that when the socket
became writable, we could sometimes already have written some of our
outgoing data to it before finding out that the connect attempt failed
- which meant we'd discard that data from the bufchain, and no longer
have it to send through a later successful connection to a different
candidate address.
If the length field in the input data was so large that adding 4 to it
caused wraparound, the error check could fail to trigger. Fortunately,
this praticular get_ssh_string function is only used during private
key import from foreign file formats, so it won't be facing hostile
data.
In case of connection errors before and during the handshake,
net_select_result is retrying with the next address of the server. It
however was immediately going to the last address as it was not
checking the return value of try_connect for all intermediate
addresses.
The .htaccess written by Buildscr into the w64 directory was applying
a redirect from 'putty-installer.msi', but in fact the name by which
the website links to snapshot and prerelease installers in that
directory is 'putty-64bit-installer.msi'.
The code that copies the link maps of the release Windows builds into
the place I store them for later debugging should now not
embarrassingly look in the wrong place when we make our first
post-VS2015 release.
I've now made a new section about how to turn on pre-release mode,
because although it's been carefully made trivial within the website
repo itself, there are still several things in other places I need to
edit.
Also added a note to myself to turn off nightly pre-release builds
after the release has gone out. I found on a previous occasion that my
build machine had been building them for months after they were
needed, which was harmless to the website but a waste of CPU!
This arranges that the mechanism from the previous commit
automatically turns itself on and off depending on whether a .git
directory even exists (so it won't try to do anything in distribution
tarballs), and also arranges that it can be manually turned off by a
configure option (in case someone who _is_ building from a git
checkout finds it inconvenient for some reason I haven't thought of,
which seems quite plausible to me).
This is perhaps the more useful end of the mechanism I added in the
previous commit: now, when a developer runs a configure+make build
from a git checkout (rather than from a bob-built source tarball), the
Makefile will automatically run 'git rev-parse HEAD' and embed the
result in the binaries.
So now when I want to deploy my own bleeding-edge code for day-to-day
use on my own machine, I can easily check whether I've done it right
(e.g. did I install to the right prefix?), and also easily check
whether any given PuTTY or pterm has been restarted since I rolled out
a new version.
In order to arrange this (and in particular to force version.o to be
rebuilt when _any_ source file changes), I've had to reintroduce some
of the slightly painful Makefile nastiness that I removed in 4d8782e74
when I retired the 'manifest' system, namely having version.o depend
on a file empty.h, which in turn is trivially rebuilt by a custom make
rule whose dependencies include $(allsources). That's a bit
unfortunate, but I think acceptable: the main horribleness of the
manifest system was not that part, but the actual _manifests_, which
were there to arrange that if you modified the sources in a
distribution tarball the binaries would automatically switch to
reporting themselves as local builds rather than the version baked
into the tarball. I haven't reintroduced that part of the system: if
you check out a given git commit, modify the checked-out sources, and
build the result, the Makefile won't make any inconvenient attempts to
detect that, and the resulting build will still announce itself as the
git commit you started from.
The Windows binaries, and both Windows and Unix source archives,
output from a bob build will now include the full SHA-1 of the source
git commit in their buildinfo (hence in all the About boxes and
command-line version output).
This will be occasionally useful to me at release time (there was that
one embarrassing incident where I managed not to notice that I'd made
a release build from entirely the wrong commit), but mostly, it just
seems like an obviously useful thing to put in a general buildinfo
section now that there is one.
This shows the build platform (32- vs 64-bit in particular, and also
whether Unix GTK builds were compiled with or without the X11 pieces),
what compiler was used to build the binary, and any interesting build
options that might have been set on the make command line (especially,
but not limited to, the security-damaging ones like NO_SECURITY or
UNPROTECT). This will probably be useful all over the place, but in
particular it should allow the different Windows binaries to be told
apart!
Commits 21101c739 and 2eb952ca3 laid the groundwork for this, by
allowing the various About boxes to contain free text and also
ensuring they could be copied and pasted easily as part of a bug
report.
I'm faintly surprised I haven't needed this before. Basically it's an
allocating string formatter, like dupprintf, except that it
concatenates on to the end of a previous string. You instantiate a
strbuf, then repeatedly call strbuf_catf to append pieces of formatted
output to it, and then you can extract the whole string and free it
(separately or both in one step).
By default the VS2015 linker produces binaries with the minimum
version fields in the PE header set to 06.00, which causes XP not to
recognise them as valid binaries at all. But there's no other reason
VS2015-built binaries _can't_ run on versions of Windows as old as XP;
so here I add the link option to set those fields to 05.01 which makes
XP like them again.
This only applies to the 32-bit build, because the VS2015 64-bit
linker refuses to lower the min version field to under 06.00.
Originally added in commit 0014ffb70, and promptly reverted in
6bea4b250 when we realised that VS2003 didn't actually understand
them. But now we're building with VS2015, which does understand them,
it's actually useful to put them back in again.
Looking more closely, it turns out that VS2003 didn't actually _fail
to build_ if you passed these flags on the linker command line - it
just printed a warning and ignored them. (So there was no actual need
to revert the original change, except that it would have caused
confusion.) But that means I can add them unconditionally now, without
breaking even the legacy VS2003 build.
It's a bit conceptually incoherent anyway - if you're uninstalling
PuTTY _systemwide_ across a multi-user system, it doesn't really make
sense that you'd also want to wipe the saved sessions for the
individual user running the uninstaller.
Also, making this change to the Inno Setup uninstaller opens up a
nicer migration path to MSI for people doing large corporate rollouts:
they can upgrade to this version of the Inno Setup package, then do a
silent uninstall of it (which should now _actually_ be silent, since
this cleanup step was the thing that interrupted it otherwise) and
then a silent install of the MSI.
Our Inno Setup installer is legacy as far as I'm concerned, so there's
no point in introducing a 64-bit version of it. 64-bit PuTTY users can
use the MSI from the start, and then there'll only ever have been one
kind of installer and they won't collide with one another.
The 32- and 64-bit installers may be distinguishable by their pathname
in the build output directory, but it's better to have their actual
filenames be different as well, so they don't collide in people's
download directories.
The MSI format has a fixed field for target architecture, so there's
no way to build a single MSI that can decide at install time whether
to install 32-bit or 64-bit (or both). The best you can do along those
lines, apparently, is to have two MSI files plus a bootstrap .EXE that
decides which of them to run, and as far as I'm concerned that would
just reintroduce all the same risks and annoyances that made us want
to migrate away from .EXE installers anyway.
The downside of moving to VS2015 is that its output won't run on very
old versions of Windows. It's not yet clear whether anyone still cares
about things before, say, Win2000 or WinXP, but since my build
environment still _has_ VS2003 available, it's easy enough to build
the extra set of binaries anyway just in case. (At least for now.)
The new binaries live in a build output directory 'w32old'. As with
w64, there is no installer for them; but unlike w64, I don't intend to
add one.
Now we've got VS2015 available (and thanks to a lot of 64-bit
cleanness fixing, in particular Tim Kosse's large patch series from
August 2015) we can do this fairly easily.
The new binaries are shipped in a 'w64' directory, alongside the
just-renamed 'w32'. There is no 64-bit installer (yet).
This is a big jump from the previous VS2003. It should add a little
performance (VS2015 is a better-optimising compiler), but mostly it's
groundwork for doing other useful things such as 64-bit builds and
security-related linker features.
The downside is reduced support for very old versions of Windows,
which I'll address shortly.
This change does affect the layout of the output build directory, and
will need corresponding website changes to avoid breaking links.
'x86' was a misnomer anyway, because it was really Windows-specific
rather than just x86-specific. Calling it 'w32' will make it look less
strange to add 'w64' alongside it.
Uses the BUILDDIR mechanism I added to Makefile.vc in commit
d3db17f3e.
This change is purely internal to Buildscr, and shouldn't affect the
output of a build. It paves the way to have Buildscr run multiple
Windows builds using different compilers, by putting each one in a
different subdirectory so that their outputs don't collide.
I had mistakenly pulled a 'char' value out of a string and passed it
to x11_font_has_glyph and x11_char_struct, each of which takes its two
index bytes as int-typed parameters. But if chars are signed, that
turns high-bit-set characters into out-of-range array indices. Oops.
The range checks in x11_char_struct prevented that from causing any
problem worse than refusal to display any affected glyph. Even so,
that's not particularly helpful. Fixed by changing the index byte
parameters to unsigned char type.
I noticed today that Unix Plink responds to SIGWINCH by accidentally
dying of EINTR having interrupted its main select loop, and when I
checked, there turn out to be a couple of other select loops with the
same bug.
This is a purely stylistic cleanup - no functional change intended -
after Tim Kosse's changes in commits e9a76883a and 6f871e3d2.
I think the underlying cause of the confusion whose functional effects
he was fixing there is that I have the bad habit of tending to call
variables 'ret' for two different reasons: one is because it's holding
the value returned from some subroutine I've just called, and the
other is because it's holding the value I'm preparing to return from
the routine _containing_ the variable.
The reason it's a bad habit is that I confuse the two purposes, and a
variable of one type ends up accidentally being treated as the other.
So while Tim's commits have already fixed the functional effects of
the error in this case, this change should help prevent a recurrence
because now there's no variable called 'ret' at all that's in scope
for the whole function.
random_add_noise calls SHATransform for every 64 octets of incoming noise,
yet instead of xor'ing the hashed noise into the pool it instead only xor'ed
20 octets of the raw noise in each iteration. This effectively reduced the
amount of new entropy entering the pool.
It is possible for SSH_FXP_CLOSE requests to fail. This can happen if the
server buffers writes and an error occurs flushing the data to disk while
processing the SSH_FXP_CLOSE request. If the close fails, sftp_put_file now
returns an error as well.
Due to a shadowed variable, transfer failures were not reflected in the return
code to sftp_put_file. Instead of tracking the return code, use the 'err'
variable to decide which return code to use.
Due to the return variable 'ret' being shadowed in the transfer loop, errors
in the transfer loop did not affect the final return value of sftp_get_file.
This particularly affects psftp's batch mode (without passing the -be
command-line argument), which would errorneously continue. The solution is
to simply remove the shadowing declaration.
