Gives more helpful messages if Unix pageant ends up being a client for,
say, OpenSSH's ssh-agent, or indeed an older version of Pageant.
(Also, tweak a couple of other messages that still assumed that
pageant-as-client always talks to Pageant-as-agent.)
The protocol already allowed adding an encrypted form to a cleartext key
already held by the agent, and you might want to do so if, say, the key
happened to originally be added in cleartext-only form but you want to
be able to forget that with 'pageant -R' in future.
Now the Remove button is disabled if there aren't any keys at all
loaded, and the Re-encrypt button is disabled if no key is currently
in a state where it's decrypted but re-encryptable.
Not quite sure how that happened! But at some point in the past, a bunch
of other definitions in winpgnt.c managed to get in between the first
few IDM_FOO constants and the last few. Bring them all back together.
I'm tired of remembering all those fiddly magic numbers and copying
them back and forth between the .rc file and the source code. I'm even
more tired of having to remember that in the long string of numbers
after a dialog item definition, the first one of them _isn't_ one of
the position and size coordinates. I've given them all symbolic names,
like they should have had all along.
I think I originally didn't bother because this was such a small GUI
compared to the much larger one in PuTTY proper. But it's growing!
This causes the main key list window to open when Pageant starts up,
instead of waiting until you select 'View Keys' from the systray menu.
My main motivation for adding this option is for development: if I'm
_working_ on some detail of the key list window, it cuts down
keystrokes in my edit-compile-retry cycle if I can have it
automatically pop up in every new test run of Pageant.
Normally I'd solve that by hacking an extra couple of lines
temporarily into the code while I was doing that piece of development.
But it suddenly struck me that there's no reason _not_ to add an
option like this permanently (the space of word-length command-line
flags is huge, and that particular one is unlikely to be needed for a
different meaning), and who knows, it _might_ come in useful to
someone in normal use. And at the very least it'll save me doing
another temporary hack the next time I'm doing development work on the
Pageant GUI. So I'll leave it in.
I've decided that it was a mistake to use -E as the option for adding
keys encrypted, because it's better to use it as a fingerprint type
selector for the Pageant client side. That way it works the same as
command-line PuTTYgen, and also OpenSSH ssh-add (and ssh-keygen).
What spelling(s) to use instead for the option to add keys encrypted?
Obviously, the same ones I've just decided on for Windows Pageant;
there's no sensible reason to make them different.
On a system with 2 or more displays with different DPI settings,
moving the PuTTY window from one display to another will make Windows
resize the window using its "bitmap" strategy, stretching/compressing
the text, making it fuzzy and harder to read. This change makes PuTTY
resize its window and font size to accurately fit the DPI of the
display it is on.
We process the WM_DPICHANGED message, saving the new DPI, window size
and position. We proceed to then reset the window, recreating the
fonts using the new DPI and calculate the new window size and position
based on the new font size, user display options (ie. with/without
scrollbar) and the suggested window position provided by Windows. The
suggested window size is usually not a perfect fit, therefore we must
add a small offset to the new window position in order to avoid issues
with repeated DPI changes while dragging the window from one display
to another.
If the prompt got big enough to reach to the edges of the dialog box,
it looked ugly without any margins. Previously I hadn't noticed,
because the prompt text was never that big.
I've merged the two previous functions, with different return types
per SSH version, into a single one that returns the containing
PageantKey instead of pulling out one of its internal fields.
This actually fixes a bug, though it would only have come up in the
Unix Pageant debugging mode: an encrypted-only key would have
terminated the key list in the diagnostic messages, because
pageant_nth_ssh2_key would have returned pk->skey which was NULL. Now
it returns pk itself, which isn't.
We're no longer calling pageant_nth_ssh*_key or pageant_add_ssh*_key
from outside pageant.c. Remove them from pageant.h and turn them
static, so that we carry on not doing so.
The GUI loop that responded to the 'Remove Key' button in the key list
worked by actually trying to retrieve a pointer to the ssh_key for a
stored key, and then passing that back to the delete function. But
when a key is encrypted, that pointer is NULL, so we segfaulted.
Fixed by changing pageant_delete_ssh2_key() to take a numeric index in
the list instead of a key pointer.
This makes Windows Pageant's slightly ad-hoc command-line handling a
bit more like a standard option loop: we start by deciding whether we
think any given argument _is_ an option or not, and if we think it is,
we give an error message if it's one we don't recognise.
Now Windows Pageant has two clearly distinct dialog boxes for
requesting a key passphrase: one to use synchronously when the user
has just used the 'Add Key' GUI action, and one to use asynchronously
in response to an agent client's attempt to use a key that was loaded
encrypted.
Also fixed the wording in the asynchronous box: there were two copies
of the 'enter passphrase' instruction, one from the dialog definition
in pageant.rc file and one from the cross-platform pageant.c. Now
pageant.c doesn't format a whole user-facing message any more: it
leaves that to the platform front end to do it the way it wants.
I've also added a call to SetForegroundWindow, to try to get the
passphrase prompt into the foreground. In my experience this doesn't
actually get it the keyboard focus, which I think is deliberate on
Windows's part and there's nothing I can do about it. But at least the
user should _see_ that the prompt is there, so they can focus it
themself.
Now they have '(encrypted)' or '(re-encryptable)' after them, the same
as Unix Pageant.
Mostly this just involved tinkering with the code in winpgnt.c that
makes up the entry to put in the list box. But I also had to sprinkle
a few more calls to keylist_update() into the cross-platform
pageant.c, to make sure that the key list window is proactively
updated whenever a key is decrypted, re-encrypted, or loaded in
encrypted-only form.
The advantage of this API is that it gives us the extra flags saying
whether each key is encrypted or re-encryptable.
NFC: we don't yet do anything with that information, just make it
available for future work.
Correct MinGW format checking depends on the __MINGW_PRINTF_FORMAT
macro, which is defined in its stdio.h. cbfba7a0e9 moved the use of
that macro to before the inclusion of stdio.h, introducing spurious
"unknown conversion type character 'z'" and similar warnings.
The next version of the Internet-Draft for Argon2 has come out, and it
resolves the discrepancy between the Argon2i algorithm description and
the test vector.
The resolution is the same one I'd already guessed: the PDF in the
github repo, the C reference implementation in the same repo, and the
test vector in the I-D all agreed with each other, and only the
algorithm spec in the I-D disagreed with them all. The latter has been
corrected, so now all four sources agree with each other, and also
agree with my code.
So now everything is consistent and I don't have to have a comment
explaining which side I came down on.
Finally! Now all the previous commits have put the infrastructure in
place to fall back to the old fingerprint if you need to, we can
switch to the new format without a total compatibility break.
Now you can press 'i' at the host key prompt, and it will print all
the key fingerprints we know about, plus the full public key. So if
you wanted to check against a fingerprint type that wasn't the one
shown in the default prompt, you can see all the ones we've got.
Now we pass the whole set of fingerprints, and also a displayable
format for the full host public key.
NFC: this commit doesn't modify any of the host key prompts to _use_
any of the new information. That's coming next.
verify_ssh_manual_host_key() now takes an array of all key
fingerprints instead of just the default type, which means that an
expected key fingerprint stored in the session configuration can now
be matched against any of them.
There's actually never any need to store a host key fingerprint in the
coroutine state. The only time we pass it outside the coroutine is
when it goes to verify_ssh_manual_host_key, which returns
synchronously without keeping a copy, and when it goes to
seat_verify_ssh_host_key. And in fact all current implementations of
the latter will keep their own copy of the fingerprint, even if
they're going to be asynchronous. So it's safe to free our copy
immediately seat_verify_ssh_host_key returns, even if it's launched an
async dialog box.
The corresponding code in SSH-1 was already working this way. Storing
the fingerprint in the SSH-2 coroutine state was overcautious all
along.
The callback-function API in pageant.h for key enumeration is modified
so that we pass an array of all the available fingerprints for each
key.
In Unix Pageant, that's used by the -l option to print whichever
fingerprint the user asked for. (Unfortunately, the option name -E is
already taken, so for the moment I've called it --fptype. I may
revisit that later.)
Also, when matching a key by fingerprint, we're prepared to match
against any fingerprint type we know, with disambiguating prefixes if
necessary (e.g. you can match "md5🆎12" or "sha256:Ab12". That has
to be done a bit carefully, because we match MD5 hex fingerprints
case-insensitively, but SHA256 fingerprints are case-sensitive.
ssh2_all_fingerprints() and friends will return a small 'char **'
array, containing all the fingerprints of a key that we know how to
generate, indexed by the FingerprintType enum. The result requires
complex freeing, so there's an ssh2_free_all_fingerprints as well.
For SSH-1 RSA keys, we refuse to generate any fingerprint except the
old SSH-1 MD5 version, because there's no other fingerprint type I
know of that anyone else uses. So I've got a function that returns the
same 'char **' for an SSH-1 key, but it only fills in the MD5 slot,
and leaves the rest NULL.
As a result, I also need a dynamic function that takes a fingerprint
list and returns the id of the most preferred fingerprint type in it
_that actually exists_.
NFC: this API is introduced, but not yet used.
