At least on systems providing SetDefaultDllDirectories, this should
stop PuTTY from being willing to load DLLs from its containing
directory - which makes no difference when it's been properly
installed (in which case the application dir contains no DLLs anyway),
but does if it's being run from somewhere uncontrolled like a browser
downloads directory.
Preliminary testing suggests that this shouldn't break any existing
deliberate use of DLLs, including GSSAPI providers.
I can't believe this codebase is around 20 years old and has had
multiple giant const-fixing patches, and yet there are _still_ things
that should have been const for years and aren't.
Ahem. Cut-and-paste goof that I introduced in commit 2eb952ca3, when I
moved the application names out of separate text controls in the
resource-file dialog descriptions.
We also have the special-purpose -DUNPROTECT to disable just the ACL
changes, but if you want to compile without any Windows security API
support at all (e.g. experimentally building against winelib) then
it's easier not to have to specify both defines separately.
It's only a warning; Windows PuTTYgen puts it up as a message box, and
will still generate the key if you click yes, and Unix PuTTYgen just
prints the warning and gets on with generation anyway. But it might
help encourage people to move away from 1024-bit keys, if they're
still using them.
Protecting our processes from outside interference need not be limited
to just PuTTY: there's no reason why the other SSH-speaking tools
shouldn't have the same treatment (PSFTP, PSCP, Plink), and PuTTYgen
and Pageant which handle private key material.
Jacob pointed out that a free-text field for entering a key size in
bits is all very well for key types where we actually _can_ generate a
key to a size of your choice, but less useful for key types where
there are only three (or one) legal values for the field, especially
if we don't _say_ what they are.
So I've revamped the UI a bit: now, in ECDSA mode, you get a dropdown
list selector showing the available elliptic curves (and they're even
named, rather than just given by bit count), and in ED25519 mode even
that disappears. The curve selector for ECDSA and the bits selector
for RSA/DSA are independent controls, so each one remembers its last
known value even while temporarily hidden in favour of the other.
The actual generation function still expects a bit count rather than
an actual curve or algorithm ID, so the easiest way to actually
arrange to populate the drop-down list was to have an array of bit
counts exposed by sshecc.c. That's a bit ugly, but there we go.
One small functional change: if you enter an absurdly low value into
the RSA/DSA bit count box (under 256), PuTTYgen used to give a warning
and reset it to 256. Now it resets it to the default key length of
2048, basically because I was touching that code anyway to change a
variable name and just couldn't bring myself to leave it in a state
where it intentionally chose such an utterly useless key size. Of
course this doesn't prevent generation of 256-bit keys if someone
still really wants one - it just means they don't get one selected as
the result of a typo.
Now all the uses of the licence text or the short copyright notice get
it from a new header "licence.h", which in turn is built by a Perl
script licence.pl invoked by mkfiles.pl, using LICENCE itself as the
source.
Hence, I can completely remove a whole section from the list of
licence locations in CHECKLST.txt :-)
This makes the About and Licence boxes copy-and-pasteable, similarly
to what I've just done on Unix.
(But unlike on the Unix side, here I haven't touched the host key
prompt dialog, because that's a standard Windows MessageBox and not
easy to mess around with. Plus, in any case, you can already hit ^C to
copy the whole text out of a MessageBox. Same goes for the PGP
fingerprints dialog.)
As a side effect, several copies of the copyright notice and licence
text have moved from .rc files into C source. I've updated
CHECKLST.txt, but they won't stay there for long.
We are passing pointers as third argument to AppendMenu. Do not
truncate them to UINT, use UINT_PTR instead which has the required
size on 64bit Windows.
The menu options and radio buttons for key type were not consistently
setting each other when selected: in particular, selecting from the
menu did not cause the ED25519 radio button to be either set or unset
when that would have been appropriate.
Looks as if I failed to catch in code review the fact that we should
have _one_ call to each of CheckRadioButton and CheckMenuRadioItem,
and they should both have the right 'first' and 'last' parameters
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
The ec_name_to_curve and ec_curve_to_name functions shouldn't really
have had to exist at all: whenever any part of the PuTTY codebase
starts using sshecc.c, it's starting from an ssh_signkey or ssh_kex
pointer already found by some other means. So if we make sure not to
lose that pointer, we should never need to do any string-based lookups
to find the curve we want, and conversely, when we need to know the
name of our curve or our algorithm, we should be able to look it up as
a straightforward const char * starting from the algorithm pointer.
This commit cleans things up so that that is indeed what happens. The
ssh_signkey and ssh_kex structures defined in sshecc.c now have
'extra' fields containing pointers to all the necessary stuff;
ec_name_to_curve and ec_curve_to_name have been completely removed;
struct ec_curve has a string field giving the curve's name (but only
for those curves which _have_ a name exposed in the wire protocol,
i.e. the three NIST ones); struct ec_key keeps a pointer to the
ssh_signkey it started from, and uses that to remember the algorithm
name rather than reconstructing it from the curve. And I think I've
got rid of all the ad-hockery scattered around the code that switches
on curve->fieldBits or manually constructs curve names using stuff
like sprintf("nistp%d"); the only remaining switch on fieldBits
(necessary because that's the UI for choosing a curve in PuTTYgen) is
at least centralised into one place in sshecc.c.
One user-visible result is that the format of ed25519 host keys in the
registry has changed: there's now no curve name prefix on them,
because I think it's not really right to make up a name to use. So any
early adopters who've been using snapshot PuTTY in the last week will
be inconvenienced; sorry about that.
Adding an extra radio button to the key-type selector caused it to
wrap on to another line and push the bottom of the containing control
box down off the bottom of the window.
In the long term, should more public key formats continue to appear,
we'll probably have to replace the radio buttons with something more
extensible like a drop-down list. For the moment, though, I've fixed
it by just reducing the space per radio button to bring all five
controls back on to the same line.
To fit the text into the smaller space, I also removed the 'SSH-2'
prefix on each key type, which ought to be unnecessary these days
since SSH-2 is a well established default. Only the SSH-1 RSA key type
is still labelled with an SSH version. (And I've moved it to the far
end rather than the start of the line, while I'm here.)
There were ad-hoc functions for fingerprinting a bare key blob in both
cmdgen.c and pageant.c, not quite doing the same thing. Also, every
SSH-2 public key algorithm in the code base included a dedicated
fingerprint() method, which is completely pointless since SSH-2 key
fingerprints are computed in an algorithm-independent way (just hash
the standard-format public key blob), so each of those methods was
just duplicating the work of the public_blob() method with a less
general output mechanism.
Now sshpubk.c centrally provides an ssh2_fingerprint_blob() function
that does all the real work, plus an ssh2_fingerprint() function that
wraps it and deals with calling public_blob() to get something to
fingerprint. And the fingerprint() method has been completely removed
from ssh_signkey and all its implementations, and good riddance.
There was a fair amount of duplication between Windows and Unix
PuTTYgen, and some confusion over writing things to FILE * and
formatting them internally into strings. I think all the public-key
output code now lives in sshpubk.c, and there's only one copy of the
code to generate each format.
When I implemented reading and writing of the new format a couple of
weeks ago, I kept them strictly separate in the UI, so you have to ask
for the format you want when exporting. But in fact this is silly,
because not every key type can be saved in both formats, and OpenSSH
itself has the policy of using the old format for key types it can
handle, unless specifically asked to use the new one.
So I've now arranged that the key file format enum has three values
for OpenSSH: PEM, NEW and AUTO. Files being loaded are identified as
either PEM or NEW, which describe the two physical file formats. But
exporting UIs present either AUTO or NEW, where AUTO is the virtual
format meaning 'save in the old format if possible, otherwise the new
one'.
It's all very well for these two different formats to share a type
code as long as we're only loading them and not saving, but as soon as
we need to save one or the other, we'll need different type codes
after all.
This commit introduces the openssh_new_write() function, but for the
moment, it always returns failure.
Pageant's list box needs its tab stops reorganised a little for new
tendencies in string length, and also has to cope with there only
being one prefix space in the output of the new string fingerprint
function. PuTTYgen needs to squash more radio buttons on to one line.
This provides support for ECDSA public keys, for both hosts and users,
and also ECDH key exchange. Supported curves are currently just the
three NIST curves required by RFC 5656.
The OpenSSH key importer and exporter were structured in the
assumption that the strong commonality of format between OpenSSH RSA
and DSA keys would persist across all key types. Moved code around so
it's now clear that this is a peculiarity of those _particular_ two
key types which will not apply to others we add alongside them.
Also, a boolean 'is_dsa' in winpgen.c has been converted into a more
sensible key type enumeration, and the individually typed key pointers
have been piled on top of each other in a union.
This is a pure refactoring change which should have no functional
effect.
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]
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]
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]
and various calls to WinHelp() have been centralised into a new file
winhelp.c, which in turn has been modified to detect a .CHM file as
well as .HLP and select between them as appropriate. It explicitly
tries to load HHCTRL.OCX and use GetProcAddress, meaning that it
_should_ still work correctly on pre-HTML-Help platforms, falling
gracefully back to WinHelp, but although I tested this by
temporarily renaming my own HHCTRL.OCX I haven't yet been able to
test it on a real HTML-Help-free platform.
Also in this checkin: a new .but file and docs makefile changes to
make it convenient to build the sources for a .CHM. As yet, owing to
limitations of Halibut's CHM support, I'm not able to write a .CHM
directly, more's the pity.
[originally from svn r7000]
our app-private window messages, which is considerably higher than the
WM_XUSER we arbitrarily chose. (This isn't known to be causing any actual
problems. The fix seems not to have obviously broken anything.)
[originally from svn r6183]
[this svn revision also touched putty-wishlist]
* All the PuTTY tools for Windows and Unix now contain the fingerprints of
the Master Keys. The method for accessing them is crude but universal:
a new "-pgpfp" command-line option. (Except Unix PuTTYgen, which takes
"--pgpfp" just to be awkward.)
* Move the key policy discussion from putty-website/keys.html to
putty/doc/pgpkeys.but, and autogenerate the former from the latter.
Also tweak the text somewhat and include the fingerprints of the
Master Keys themselves.
(I've merged the existing autogeneration scripts into a single new
one; I've left the old scripts and keys.html around until such time
as the webmonster reviews the changes and plumbs in the new script;
he should remove the old files then.)
[originally from svn r5524]
[this svn revision also touched putty-website]
discussed. Use Barrett and Silverman's convention of "SSH-1" for SSH protocol
version 1 and "SSH-2" for protocol 2 ("SSH1"/"SSH2" refer to ssh.com
implementations in this scheme). <http://www.snailbook.com/terms.html>
[originally from svn r5480]
I wanted to get to -- "software caused connection abort" and friends --
are going to be more involved (probably requiring some cross-platform
notion of help contexts), and these ones hardly seem worth the effort.
Still, I've done it now.
Side-effect: Pageant now uses the same `hinst' and `hwnd' globals as
everything else. Tested basic functionality.
[originally from svn r5417]
still only used for the host key popups. Side-effects:
- requested_help is a winstuff.h global
- Pageant now defines winstuff.h globals
(Also, my previous fix to my improved host-key dialogs only got the "changed"
case, not the "unknown" case. Some days I shouldn't be let near a keyboard.)
[originally from svn r5415]
- will now display a reason when it fails to load a key
- uses existing error return from native keys
- import.c had a lot of error descriptions which weren't going anywhere;
since the strings are probably taking up space in the binary, we
may as well use them
[originally from svn r5408]
Fixes crashes when time() returns (time_t)-1 on Windows by using the
Win32 GetLocalTime() function. (The Unix implementation still just
uses time() and localtime().)
[originally from svn r5086]
timing.c, and hence takes its own responsibility for calling
noise_regular() at regular intervals. Again, this means it will be
called consistently in _all_ the SSH-speaking tools, not just those
in which I remembered to call it!
[originally from svn r4913]
long last to move all the Windows-specific source files down into a
`windows' subdirectory. Only platform-specific files remain at the
top level. With any luck this will act as a hint to anyone still
contemplating sending us a Windows-centric patch...
[originally from svn r4792]
