I listed a lot of other build options, but not that one. The release
checklist still recommends doing test builds with it, so it seems
sensible to arrange that you can tell if a build _is_ one of those or
not.
Ilya Shipitsin sent me a list of errors reported by a tool 'cppcheck',
which I hadn't seen before, together with some fixes for things
already taken off that list. This change picks out all the things from
the remaining list that I could quickly identify as actual errors,
which it turns out are all format-string goofs along the lines of
using a %d with an unsigned int, or a %u with a signed int, or (in the
cases in charset/utf8.c) an actual _size_ mismatch which could in
principle have caused trouble on a big-endian target.
In particular, this means the w32 and w32old builds have
distinguishable buildinfo text, which should protect us against at
least one source of confusion when receiving bug reports.
Thanks to Tim Kosse for pointing out that I had _completely_ cocked up
all the code that was supposed to enlarge the buffer in the strbuf
structure, by failing to pass in 'oldsize' to the innermost
dupvprintf_inner function by reference, so that the size was never
updated.
Fortunately, this whole mechanism was something I dashed off for the
purposes of buildinfo(), which means it's only ever used to glue
together a fixed number of compile-time string constants, for which
there turns out to be plenty to spare in the standard 512 bytes
allocated to a new strbuf. So it's at least not dangerous, though it
clearly needs to be fixed before I make the mistake of using
strbuf_catf[v] for anything else!
It's obvious to the trained eye whether GTK PuTTY was compiled against
GTK2 or GTK3, but the untrained eye would probably appreciate a little
help, and even the trained eye probably can't tell GTK 3.18 from 3.19
at a glance :-)
Avoided referring to some functions and header files that aren't there
in the winelib world (_vsnprintf, _stricmp, SecureZeroMemory,
multimon.h), and worked around a really amazingly annoying issue in
which Winelib objects to you using the type 'fd_set' unless you
included winsock2.h before stdlib.h.
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.
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).
Proper snprintf is finally supported as of the latest Visual Studio,
and has better semantics for my purposes than the old MS-specific
_snprintf. (Specifically, if its output doesn't fit the buffer, it
returns the full size it _would_ have wanted, so that you can then
immediately allocate that much space, and don't have to keep going
round a loop increasing the buffer size until you find the answer.)
The initial test for a line ending with "PRIVATE KEY-----" failed to
take into account the possibility that the line might be shorter than
that. Fixed by introducing a new library function strendswith(), and
strstartswith() for good measure, and using that.
Thanks to Hanno Böck for spotting this, with the aid of AFL.
Having found a lot of unfixed constness issues in recent development,
I thought perhaps it was time to get proactive, so I compiled the
whole codebase with -Wwrite-strings. That turned up a huge load of
const problems, which I've fixed in this commit: the Unix build now
goes cleanly through with -Wwrite-strings, and the Windows build is as
close as I could get it (there are some lingering issues due to
occasional Windows API functions like AcquireCredentialsHandle not
having the right constness).
Notable fallout beyond the purely mechanical changing of types:
- the stuff saved by cmdline_save_param() is now explicitly
dupstr()ed, and freed in cmdline_run_saved.
- I couldn't make both string arguments to cmdline_process_param()
const, because it intentionally writes to one of them in the case
where it's the argument to -pw (in the vain hope of being at least
slightly friendly to 'ps'), so elsewhere I had to temporarily
dupstr() something for the sake of passing it to that function
- I had to invent a silly parallel version of const_cmp() so I could
pass const string literals in to lookup functions.
- stripslashes() in pscp.c and psftp.c has the annoying strchr nature
I'm finding missing constifications all over the place this week.
Turns out that dmemdump() has been taking a non-const memory pointer
ever since the beginning, and it's never come up until now. How silly.
I'm about to use these in a new piece of code, but they may come in
helpful elsewhere as well. match_ssh_id in particular wraps an idiom
that's quite common in the rest of the codebase.
Now that we have modes in which the MAC verification happens before
any other crypto operation and hence will be the only thing seen by an
attacker, it seems like about time we got round to doing it in a
cautious way that tries to prevent the attacker from using our memcmp
as a timing oracle.
So, here's an smemeq() function which has the semantics of !memcmp but
attempts to run in time dependent only on the length parameter. All
the MAC implementations now use this in place of !memcmp to verify the
MAC on input data.
'p += strcspn' returns p always non-NULL and sometimes pointing at \0,
as opposed to 'p = strchr' which returns p sometimes non-NULL and
never pointing at \0. Test the pointer after the call accordingly.
Thanks, Coverity.
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]
I'm about to need to refer to it from a source file that won't
necessarily always be linked against sshpubk.c, so it needs to live
somewhere less specialist. Now it sits alongside base64_encode_atom
(already in misc.c for another reason), which is neater anyway.
[originally from svn r10218]
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]
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]
bufchain_add() now allocates at most one new granule. Granules still
have a minimum size, so small adds still get coalesced.
The main practical consequence of this is that PSCP and PSFTP now
generate 4K SSH packets rather than 512-byte ones. Also, the compiled
code (on my Ubuntu box) is fractionally smaller.
[originally from svn r9602]
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]
'Config' in putty.h, which stores all PuTTY's settings and includes an
arbitrary length limit on every single one of those settings which is
stored in string form. In place of it is 'Conf', an opaque data type
everywhere outside the new file conf.c, which stores a list of (key,
value) pairs in which every key contains an integer identifying a
configuration setting, and for some of those integers the key also
contains extra parts (so that, for instance, CONF_environmt is a
string-to-string mapping). Everywhere that a Config was previously
used, a Conf is now; everywhere there was a Config structure copy,
conf_copy() is called; every lookup, adjustment, load and save
operation on a Config has been rewritten; and there's a mechanism for
serialising a Conf into a binary blob and back for use with Duplicate
Session.
User-visible effects of this change _should_ be minimal, though I
don't doubt I've introduced one or two bugs here and there which will
eventually be found. The _intended_ visible effects of this change are
that all arbitrary limits on configuration strings and lists (e.g.
limit on number of port forwardings) should now disappear; that list
boxes in the configuration will now be displayed in a sorted order
rather than the arbitrary order in which they were added to the list
(since the underlying data structure is now a sorted tree234 rather
than an ad-hoc comma-separated string); and one more specific change,
which is that local and dynamic port forwardings on the same port
number are now mutually exclusive in the configuration (putting 'D' in
the key rather than the value was a mistake in the first place).
One other reorganisation as a result of this is that I've moved all
the dialog.c standard handlers (dlg_stdeditbox_handler and friends)
out into config.c, because I can't really justify calling them generic
any more. When they took a pointer to an arbitrary structure type and
the offset of a field within that structure, they were independent of
whether that structure was a Config or something completely different,
but now they really do expect to talk to a Conf, which can _only_ be
used for PuTTY configuration, so I've renamed them all things like
conf_editbox_handler and moved them out of the nominally independent
dialog-box management module into the PuTTY-specific config.c.
[originally from svn r9214]
another to shut up "warning: cast from pointer to integer of different size"
(and hence a -Werror compile failure) when compiling for Unix with DEBUG
defined on atreus (x86_64). Minimally checked that it doesn't introduce upset
elsewhere (i386).
[originally from svn r8380]
(Since we choose to compile with -Werror, this is particularly important.)
I haven't yet checked that the resulting source actually compiles cleanly with
GCC 4, hence not marking `gcc4-warnings' as fixed just yet.
[originally from svn r7041]
on AMD 64 Linux.
(This has been sitting in my checkout for ages and hasn't obviously caused
any trouble -- I think I was waiting to get round to trying it with VC6, which
I haven't yet. There are some notes in comments on further tweaks that could
be made.)
[originally from svn r7035]
in place of making a network connection. This has involved a couple
of minor infrastructure changes:
- New dlg_label_change() function in the dialog.h interface, which
alters the label on a control. Only used, at present, to switch
the Host Name and Port boxes into Serial Line and Speed, which
means that any platform not implementing serial connections (i.e.
currently all but Windows) does not need to actually do anything
in this function. Yet.
- New small piece of infrastructure: cfg_launchable() determines
whether a Config structure describes a session ready to be
launched. This was previously determined by seeing if it had a
non-empty host name, but it has to check the serial line as well
so there's a centralised function for it. I haven't gone through
all front ends and arranged for this function to be used
everywhere it needs to be; so far I've only checked Windows.
- Similarly, cfg_dest() returns the destination of a connection
(host name or serial line) in a text format suitable for putting
into messages such as `Unable to connect to %s'.
[originally from svn r6815]
abstracted out; replace loops structured around a single interaction
per loop with less tortuous code (fixes: `ki-multiprompt-crash',
`ssh1-bad-passphrase-crash'; makes `ssh2-password-expiry' and
`proxy-password-prompt' easier).
The new interaction abstraction has a lot of fields that are unused in
the current code (things like window captions); this is groundwork for
`gui-auth'. However, ssh.c still writes directly to stderr; that may
want to be fixed.
In the GUI apps, user interaction is moved to terminal.c. This should
make it easier to fix things like UTF-8 username entry, although I
haven't attempted to do so. Also, control character filtering can be
tailored to be appropriate for individual front-ends; so far I don't
promise anything other than not having made it any worse.
I've tried to test this fairly exhaustively (although Mac stuff is
untested, as usual). It all seems to basically work, but I bet there
are new bugs. (One I know about is that you can no longer make the
PuTTY window go away with a ^D at the password prompt; this should be
fixed.)
[originally from svn r6437]
[this svn revision also touched putty-wishlist]
which pretty much any module can call to request a call-back in the
future. So terminal.c can do its own handling of blinking, visual
bells and deferred screen updates, without having to rely on
term_update() being called 50 times a second (fixes: pterm-timer);
and ssh.c and telnet.c both invoke a new module pinger.c which takes
care of sending keepalives, so they get sent uniformly in all front
ends (fixes: plink-keepalives, unix-keepalives).
[originally from svn r4906]
[this svn revision also touched putty-wishlist]
from_backend() interface, after having made all implementations safe against
being called with len==0 and possibly-NULL/undefined "data".
(This includes making misc.c:bufchain_add() more robust in this area.)
Assertion was originally added 2002-03-01; e.g., see plink.c:1.53 [r1571].
I believe this now shouldn't break anything.
This should hopefully make `ppk-empty-comment' finally GO AWAY. (Tested
with Unix PuTTY.)
[originally from svn r3500]
[r1571 == fdbd697801]
malloc functions, which automatically cast to the same type they're
allocating the size of. Should prevent any future errors involving
mallocing the size of the wrong structure type, and will also make
life easier if we ever need to turn the PuTTY core code from real C
into C++-friendly C. I haven't touched the Mac frontend in this
checkin because I couldn't compile or test it.
[originally from svn r3014]
