2000-09-14 15:02:50 +00:00
|
|
|
/*
|
|
|
|
* Pageant: the PuTTY Authentication Agent.
|
|
|
|
*/
|
|
|
|
|
2000-09-28 08:35:20 +00:00
|
|
|
#include <stdio.h>
|
2000-10-24 10:47:49 +00:00
|
|
|
#include <stdlib.h>
|
winpgnt.c: handle arbitrarily large file mappings.
I heard recently that at least one third-party client of Pageant
exists, and that it's used to generate signatures to use with TLS
client certificates. Apparently the signature scheme is compatible,
but TLS tends to need signatures over more data than will fit in
AGENT_MAX_MSGLEN.
Before the BinarySink refactor in commit b6cbad89f, this was OK
because the Windows Pageant IPC didn't check the size of the _input_
message against AGENT_MAX_MSGLEN, only the output one. But then we
started checking both, so that third-party TLS client started failing.
Now we use VirtualQuery to find out the actual size of the file
mapping we've been passed, and our only requirement is that the input
and output messages should both fit in _that_. So TLS should work
again, and also, other clients should be able to retrieve longer lists
of public keys if they pass a larger file mapping.
One side effect of this change is that Pageant's reply message is now
written directly into the shared-memory region. Previously, it was
written into a separate buffer and then memcpy()ed over after
pageant_handle_msg returned, but now the buffer is variable-size, it
seems to me to make more sense to avoid that extra not-entirely
controlled malloc. So I've done one very small reordering of
statements in the cross-platform pageant_handle_msg(), which fixes the
only case I could find where that function started writing its output
before it had finished using the contents of the input buffer.
2018-07-08 15:46:32 +00:00
|
|
|
#include <stddef.h>
|
2000-10-24 10:47:49 +00:00
|
|
|
#include <ctype.h>
|
2001-12-30 15:58:17 +00:00
|
|
|
#include <assert.h>
|
2001-04-16 11:16:58 +00:00
|
|
|
#include <tchar.h>
|
|
|
|
|
2003-02-01 12:54:40 +00:00
|
|
|
#include "putty.h"
|
2000-09-14 15:02:50 +00:00
|
|
|
#include "ssh.h"
|
2001-12-11 18:48:29 +00:00
|
|
|
#include "misc.h"
|
2000-09-14 15:02:50 +00:00
|
|
|
#include "tree234.h"
|
2013-11-17 14:05:29 +00:00
|
|
|
#include "winsecur.h"
|
2020-01-01 15:55:06 +00:00
|
|
|
#include "wincapi.h"
|
2015-05-05 19:16:19 +00:00
|
|
|
#include "pageant.h"
|
2015-12-22 12:43:31 +00:00
|
|
|
#include "licence.h"
|
2003-10-12 13:46:12 +00:00
|
|
|
|
2004-01-20 20:35:27 +00:00
|
|
|
#include <shellapi.h>
|
|
|
|
|
2003-10-12 13:46:12 +00:00
|
|
|
#ifndef NO_SECURITY
|
|
|
|
#include <aclapi.h>
|
2011-06-08 20:47:07 +00:00
|
|
|
#ifdef DEBUG_IPC
|
|
|
|
#define _WIN32_WINNT 0x0500 /* for ConvertSidToStringSid */
|
|
|
|
#include <sddl.h>
|
|
|
|
#endif
|
2003-10-12 13:46:12 +00:00
|
|
|
#endif
|
2000-09-14 15:02:50 +00:00
|
|
|
|
|
|
|
#define IDI_MAINICON 200
|
|
|
|
#define IDI_TRAYICON 201
|
|
|
|
|
2005-08-10 18:31:24 +00:00
|
|
|
#define WM_SYSTRAY (WM_APP + 6)
|
|
|
|
#define WM_SYSTRAY2 (WM_APP + 7)
|
2000-09-19 16:29:28 +00:00
|
|
|
|
|
|
|
#define AGENT_COPYDATA_ID 0x804e50ba /* random goop */
|
|
|
|
|
2004-11-02 22:30:24 +00:00
|
|
|
/* From MSDN: In the WM_SYSCOMMAND message, the four low-order bits of
|
|
|
|
* wParam are used by Windows, and should be masked off, so we shouldn't
|
|
|
|
* attempt to store information in them. Hence all these identifiers have
|
2004-11-02 23:06:43 +00:00
|
|
|
* the low 4 bits clear. Also, identifiers should < 0xF000. */
|
2004-11-02 22:30:24 +00:00
|
|
|
|
2000-09-14 15:02:50 +00:00
|
|
|
#define IDM_CLOSE 0x0010
|
|
|
|
#define IDM_VIEWKEYS 0x0020
|
2000-10-12 15:26:40 +00:00
|
|
|
#define IDM_ADDKEY 0x0030
|
2001-12-11 18:48:29 +00:00
|
|
|
#define IDM_HELP 0x0040
|
|
|
|
#define IDM_ABOUT 0x0050
|
2000-09-14 15:02:50 +00:00
|
|
|
|
|
|
|
#define APPNAME "Pageant"
|
|
|
|
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
/* Titles and class names for invisible windows. IPCWINTITLE and
|
|
|
|
* IPCCLASSNAME are critical to backwards compatibility: WM_COPYDATA
|
|
|
|
* based Pageant clients will call FindWindow with those parameters
|
|
|
|
* and expect to find the Pageant IPC receiver. */
|
|
|
|
#define TRAYWINTITLE "Pageant"
|
|
|
|
#define TRAYCLASSNAME "PageantSysTray"
|
|
|
|
#define IPCWINTITLE "Pageant"
|
|
|
|
#define IPCCLASSNAME "Pageant"
|
|
|
|
|
2020-02-02 10:00:43 +00:00
|
|
|
static HWND traywindow;
|
2000-10-06 11:42:30 +00:00
|
|
|
static HWND keylist;
|
|
|
|
static HWND aboutbox;
|
2002-03-27 20:30:57 +00:00
|
|
|
static HMENU systray_menu, session_menu;
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
static bool already_running;
|
2001-12-11 18:48:29 +00:00
|
|
|
|
2002-03-27 20:30:57 +00:00
|
|
|
static char *putty_path;
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
static bool restrict_putty_acl = false;
|
2002-03-27 20:30:57 +00:00
|
|
|
|
2005-02-28 02:40:43 +00:00
|
|
|
/* CWD for "add key" file requester. */
|
|
|
|
static filereq *keypath = NULL;
|
|
|
|
|
2002-03-27 20:30:57 +00:00
|
|
|
#define IDM_PUTTY 0x0060
|
|
|
|
#define IDM_SESSIONS_BASE 0x1000
|
|
|
|
#define IDM_SESSIONS_MAX 0x2000
|
|
|
|
#define PUTTY_REGKEY "Software\\SimonTatham\\PuTTY\\Sessions"
|
|
|
|
#define PUTTY_DEFAULT "Default%20Settings"
|
|
|
|
static int initial_menuitems_count;
|
|
|
|
|
2002-10-09 18:09:42 +00:00
|
|
|
/*
|
|
|
|
* Print a modal (Really Bad) message box and perform a fatal exit.
|
|
|
|
*/
|
2015-05-15 10:15:42 +00:00
|
|
|
void modalfatalbox(const char *fmt, ...)
|
2002-10-09 18:09:42 +00:00
|
|
|
{
|
|
|
|
va_list ap;
|
2002-11-07 19:49:03 +00:00
|
|
|
char *buf;
|
2002-10-09 18:09:42 +00:00
|
|
|
|
|
|
|
va_start(ap, fmt);
|
2002-11-07 19:49:03 +00:00
|
|
|
buf = dupvprintf(fmt, ap);
|
2002-10-09 18:09:42 +00:00
|
|
|
va_end(ap);
|
2020-02-02 10:00:43 +00:00
|
|
|
MessageBox(traywindow, buf, "Pageant Fatal Error",
|
2019-09-08 19:29:00 +00:00
|
|
|
MB_SYSTEMMODAL | MB_ICONERROR | MB_OK);
|
2002-11-07 19:49:03 +00:00
|
|
|
sfree(buf);
|
2002-10-09 18:09:42 +00:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
static bool has_security;
|
2000-09-26 09:22:40 +00:00
|
|
|
|
2000-09-26 13:31:15 +00:00
|
|
|
struct PassphraseProcStruct {
|
2020-03-21 15:59:51 +00:00
|
|
|
bool modal;
|
|
|
|
PageantClientDialogId *dlgid;
|
|
|
|
char *passphrase;
|
|
|
|
const char *comment;
|
2000-09-26 13:31:15 +00:00
|
|
|
};
|
|
|
|
|
2000-09-29 08:43:06 +00:00
|
|
|
/*
|
|
|
|
* Dialog-box function for the Licence box.
|
|
|
|
*/
|
2015-08-11 12:22:09 +00:00
|
|
|
static INT_PTR CALLBACK LicenceProc(HWND hwnd, UINT msg,
|
2019-09-08 19:29:00 +00:00
|
|
|
WPARAM wParam, LPARAM lParam)
|
2001-05-06 14:35:20 +00:00
|
|
|
{
|
2000-09-29 08:43:06 +00:00
|
|
|
switch (msg) {
|
|
|
|
case WM_INITDIALOG:
|
2015-12-22 12:43:31 +00:00
|
|
|
SetDlgItemText(hwnd, 1000, LICENCE_TEXT("\r\n\r\n"));
|
2019-09-08 19:29:00 +00:00
|
|
|
return 1;
|
2000-09-29 08:43:06 +00:00
|
|
|
case WM_COMMAND:
|
2019-09-08 19:29:00 +00:00
|
|
|
switch (LOWORD(wParam)) {
|
|
|
|
case IDOK:
|
|
|
|
case IDCANCEL:
|
|
|
|
EndDialog(hwnd, 1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 0;
|
2000-09-29 08:43:06 +00:00
|
|
|
case WM_CLOSE:
|
2019-09-08 19:29:00 +00:00
|
|
|
EndDialog(hwnd, 1);
|
|
|
|
return 0;
|
2000-09-29 08:43:06 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Dialog-box function for the About box.
|
|
|
|
*/
|
2015-08-11 12:22:09 +00:00
|
|
|
static INT_PTR CALLBACK AboutProc(HWND hwnd, UINT msg,
|
2019-09-08 19:29:00 +00:00
|
|
|
WPARAM wParam, LPARAM lParam)
|
2001-05-06 14:35:20 +00:00
|
|
|
{
|
2000-09-29 08:43:06 +00:00
|
|
|
switch (msg) {
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
case WM_INITDIALOG: {
|
|
|
|
char *buildinfo_text = buildinfo("\r\n");
|
|
|
|
char *text = dupprintf
|
|
|
|
("Pageant\r\n\r\n%s\r\n\r\n%s\r\n\r\n%s",
|
|
|
|
ver, buildinfo_text,
|
|
|
|
"\251 " SHORT_COPYRIGHT_DETAILS ". All rights reserved.");
|
|
|
|
sfree(buildinfo_text);
|
|
|
|
SetDlgItemText(hwnd, 1000, text);
|
|
|
|
sfree(text);
|
2019-09-08 19:29:00 +00:00
|
|
|
return 1;
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
}
|
2000-09-29 08:43:06 +00:00
|
|
|
case WM_COMMAND:
|
2019-09-08 19:29:00 +00:00
|
|
|
switch (LOWORD(wParam)) {
|
|
|
|
case IDOK:
|
|
|
|
case IDCANCEL:
|
|
|
|
aboutbox = NULL;
|
|
|
|
DestroyWindow(hwnd);
|
|
|
|
return 0;
|
|
|
|
case 101:
|
|
|
|
EnableWindow(hwnd, 0);
|
|
|
|
DialogBox(hinst, MAKEINTRESOURCE(214), hwnd, LicenceProc);
|
|
|
|
EnableWindow(hwnd, 1);
|
|
|
|
SetActiveWindow(hwnd);
|
|
|
|
return 0;
|
|
|
|
case 102:
|
|
|
|
/* Load web browser */
|
|
|
|
ShellExecute(hwnd, "open",
|
|
|
|
"https://www.chiark.greenend.org.uk/~sgtatham/putty/",
|
|
|
|
0, 0, SW_SHOWDEFAULT);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 0;
|
2000-09-29 08:43:06 +00:00
|
|
|
case WM_CLOSE:
|
2019-09-08 19:29:00 +00:00
|
|
|
aboutbox = NULL;
|
|
|
|
DestroyWindow(hwnd);
|
|
|
|
return 0;
|
2000-09-29 08:43:06 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-03-21 15:59:51 +00:00
|
|
|
static HWND modal_passphrase_hwnd = NULL;
|
|
|
|
static HWND nonmodal_passphrase_hwnd = NULL;
|
|
|
|
|
|
|
|
static void end_passphrase_dialog(HWND hwnd, INT_PTR result)
|
|
|
|
{
|
|
|
|
struct PassphraseProcStruct *p = (struct PassphraseProcStruct *)
|
|
|
|
GetWindowLongPtr(hwnd, GWLP_USERDATA);
|
|
|
|
|
|
|
|
if (p->modal) {
|
|
|
|
EndDialog(hwnd, result);
|
|
|
|
} else {
|
|
|
|
if (result)
|
|
|
|
pageant_passphrase_request_success(
|
|
|
|
p->dlgid, ptrlen_from_asciz(p->passphrase));
|
|
|
|
else
|
|
|
|
pageant_passphrase_request_refused(p->dlgid);
|
|
|
|
|
|
|
|
burnstr(p->passphrase);
|
|
|
|
sfree(p);
|
|
|
|
SetWindowLongPtr(hwnd, GWLP_USERDATA, (LONG_PTR) NULL);
|
|
|
|
DestroyWindow(hwnd);
|
|
|
|
nonmodal_passphrase_hwnd = NULL;
|
|
|
|
}
|
|
|
|
}
|
2001-08-04 14:59:56 +00:00
|
|
|
|
2000-09-14 15:02:50 +00:00
|
|
|
/*
|
|
|
|
* Dialog-box function for the passphrase box.
|
|
|
|
*/
|
2015-08-11 12:22:09 +00:00
|
|
|
static INT_PTR CALLBACK PassphraseProc(HWND hwnd, UINT msg,
|
2019-09-08 19:29:00 +00:00
|
|
|
WPARAM wParam, LPARAM lParam)
|
2001-05-06 14:35:20 +00:00
|
|
|
{
|
2000-09-26 13:31:15 +00:00
|
|
|
struct PassphraseProcStruct *p;
|
2000-09-14 15:02:50 +00:00
|
|
|
|
2020-03-21 15:59:51 +00:00
|
|
|
if (msg == WM_INITDIALOG) {
|
|
|
|
p = (struct PassphraseProcStruct *) lParam;
|
|
|
|
SetWindowLongPtr(hwnd, GWLP_USERDATA, (LONG_PTR) p);
|
|
|
|
} else {
|
|
|
|
p = (struct PassphraseProcStruct *)
|
|
|
|
GetWindowLongPtr(hwnd, GWLP_USERDATA);
|
|
|
|
}
|
|
|
|
|
2000-09-14 15:02:50 +00:00
|
|
|
switch (msg) {
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
case WM_INITDIALOG: {
|
2020-03-21 15:59:51 +00:00
|
|
|
if (p->modal)
|
|
|
|
modal_passphrase_hwnd = hwnd;
|
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
/*
|
|
|
|
* Centre the window.
|
|
|
|
*/
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
RECT rs, rd;
|
|
|
|
HWND hw;
|
|
|
|
|
|
|
|
hw = GetDesktopWindow();
|
|
|
|
if (GetWindowRect(hw, &rs) && GetWindowRect(hwnd, &rd))
|
|
|
|
MoveWindow(hwnd,
|
|
|
|
(rs.right + rs.left + rd.left - rd.right) / 2,
|
|
|
|
(rs.bottom + rs.top + rd.top - rd.bottom) / 2,
|
|
|
|
rd.right - rd.left, rd.bottom - rd.top, true);
|
2019-09-08 19:29:00 +00:00
|
|
|
|
|
|
|
SetForegroundWindow(hwnd);
|
|
|
|
SetWindowPos(hwnd, HWND_TOP, 0, 0, 0, 0,
|
|
|
|
SWP_NOMOVE | SWP_NOSIZE | SWP_SHOWWINDOW);
|
2020-03-21 15:59:51 +00:00
|
|
|
if (!p->modal)
|
|
|
|
SetActiveWindow(hwnd); /* this won't have happened automatically */
|
2019-09-08 19:29:00 +00:00
|
|
|
if (p->comment)
|
|
|
|
SetDlgItemText(hwnd, 101, p->comment);
|
2020-03-21 15:59:51 +00:00
|
|
|
burnstr(p->passphrase);
|
|
|
|
p->passphrase = dupstr("");
|
|
|
|
SetDlgItemText(hwnd, 102, p->passphrase);
|
2019-09-08 19:29:00 +00:00
|
|
|
return 0;
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
}
|
2000-09-14 15:02:50 +00:00
|
|
|
case WM_COMMAND:
|
2019-09-08 19:29:00 +00:00
|
|
|
switch (LOWORD(wParam)) {
|
|
|
|
case IDOK:
|
2020-03-21 15:59:51 +00:00
|
|
|
if (p->passphrase)
|
|
|
|
end_passphrase_dialog(hwnd, 1);
|
2019-09-08 19:29:00 +00:00
|
|
|
else
|
|
|
|
MessageBeep(0);
|
|
|
|
return 0;
|
|
|
|
case IDCANCEL:
|
2020-03-21 15:59:51 +00:00
|
|
|
end_passphrase_dialog(hwnd, 0);
|
2019-09-08 19:29:00 +00:00
|
|
|
return 0;
|
|
|
|
case 102: /* edit box */
|
2020-03-21 15:59:51 +00:00
|
|
|
if ((HIWORD(wParam) == EN_CHANGE) && p->passphrase) {
|
|
|
|
burnstr(p->passphrase);
|
|
|
|
p->passphrase = GetDlgItemText_alloc(hwnd, 102);
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 0;
|
2000-09-14 15:02:50 +00:00
|
|
|
case WM_CLOSE:
|
2020-03-21 15:59:51 +00:00
|
|
|
end_passphrase_dialog(hwnd, 0);
|
2019-09-08 19:29:00 +00:00
|
|
|
return 0;
|
2000-09-14 15:02:50 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2001-11-25 14:31:46 +00:00
|
|
|
/*
|
|
|
|
* Warn about the obsolescent key file format.
|
|
|
|
*/
|
|
|
|
void old_keyfile_warning(void)
|
|
|
|
{
|
|
|
|
static const char mbtitle[] = "PuTTY Key File Warning";
|
|
|
|
static const char message[] =
|
2019-09-08 19:29:00 +00:00
|
|
|
"You are loading an SSH-2 private key which has an\n"
|
|
|
|
"old version of the file format. This means your key\n"
|
|
|
|
"file is not fully tamperproof. Future versions of\n"
|
|
|
|
"PuTTY may stop supporting this private key format,\n"
|
|
|
|
"so we recommend you convert your key to the new\n"
|
|
|
|
"format.\n"
|
|
|
|
"\n"
|
|
|
|
"You can perform this conversion by loading the key\n"
|
|
|
|
"into PuTTYgen and then saving it again.";
|
2001-11-25 14:31:46 +00:00
|
|
|
|
|
|
|
MessageBox(NULL, message, mbtitle, MB_OK);
|
|
|
|
}
|
|
|
|
|
2000-09-26 13:18:43 +00:00
|
|
|
/*
|
|
|
|
* Update the visible key list.
|
|
|
|
*/
|
2015-05-05 19:16:19 +00:00
|
|
|
void keylist_update(void)
|
2001-05-06 14:35:20 +00:00
|
|
|
{
|
2019-01-04 06:51:44 +00:00
|
|
|
RSAKey *rkey;
|
|
|
|
ssh2_userkey *skey;
|
2001-04-16 17:18:24 +00:00
|
|
|
int i;
|
2000-09-26 13:18:43 +00:00
|
|
|
|
|
|
|
if (keylist) {
|
2019-09-08 19:29:00 +00:00
|
|
|
SendDlgItemMessage(keylist, 100, LB_RESETCONTENT, 0, 0);
|
|
|
|
for (i = 0; NULL != (rkey = pageant_nth_ssh1_key(i)); i++) {
|
|
|
|
char *listentry, *fp, *p;
|
2018-06-03 07:08:53 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
fp = rsa_ssh1_fingerprint(rkey);
|
|
|
|
listentry = dupprintf("ssh1\t%s", fp);
|
2018-06-03 07:08:53 +00:00
|
|
|
sfree(fp);
|
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
/*
|
|
|
|
* Replace two spaces in the fingerprint with tabs, for
|
|
|
|
* nice alignment in the box.
|
|
|
|
*/
|
|
|
|
p = strchr(listentry, ' ');
|
|
|
|
if (p)
|
|
|
|
*p = '\t';
|
|
|
|
p = strchr(listentry, ' ');
|
|
|
|
if (p)
|
|
|
|
*p = '\t';
|
|
|
|
SendDlgItemMessage(keylist, 100, LB_ADDSTRING,
|
|
|
|
0, (LPARAM) listentry);
|
2018-06-03 07:08:53 +00:00
|
|
|
sfree(listentry);
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
|
|
|
for (i = 0; NULL != (skey = pageant_nth_ssh2_key(i)); i++) {
|
|
|
|
char *listentry, *p;
|
|
|
|
int pos;
|
2016-03-25 08:36:29 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* For nice alignment in the list box, we would ideally
|
|
|
|
* want every entry to align to the tab stop settings, and
|
|
|
|
* have a column for algorithm name, one for bit count,
|
|
|
|
* one for hex fingerprint, and one for key comment.
|
|
|
|
*
|
|
|
|
* Unfortunately, some of the algorithm names are so long
|
|
|
|
* that they overflow into the bit-count field.
|
|
|
|
* Fortunately, at the moment, those are _precisely_ the
|
|
|
|
* algorithm names that don't need a bit count displayed
|
|
|
|
* anyway (because for NIST-style ECDSA the bit count is
|
|
|
|
* mentioned in the algorithm name, and for ssh-ed25519
|
|
|
|
* there is only one possible value anyway). So we fudge
|
|
|
|
* this by simply omitting the bit count field in that
|
|
|
|
* situation.
|
|
|
|
*
|
|
|
|
* This is fragile not only in the face of further key
|
|
|
|
* types that don't follow this pattern, but also in the
|
|
|
|
* face of font metrics changes - the Windows semantics
|
|
|
|
* for list box tab stops is that \t aligns to the next
|
|
|
|
* one you haven't already exceeded, so I have to guess
|
|
|
|
* when the key type will overflow past the bit-count tab
|
|
|
|
* stop and leave out a tab character. Urgh.
|
|
|
|
*/
|
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
p = ssh2_fingerprint(skey->key);
|
2013-07-22 07:11:35 +00:00
|
|
|
listentry = dupprintf("%s\t%s", p, skey->comment);
|
|
|
|
sfree(p);
|
|
|
|
|
2014-11-01 19:33:29 +00:00
|
|
|
pos = 0;
|
|
|
|
while (1) {
|
|
|
|
pos += strcspn(listentry + pos, " :");
|
2015-08-11 11:45:26 +00:00
|
|
|
if (listentry[pos] == ':' || !listentry[pos])
|
2014-11-01 19:33:29 +00:00
|
|
|
break;
|
|
|
|
listentry[pos++] = '\t';
|
|
|
|
}
|
2018-06-03 11:58:05 +00:00
|
|
|
if (ssh_key_alg(skey->key) != &ssh_dss &&
|
|
|
|
ssh_key_alg(skey->key) != &ssh_rsa) {
|
2016-03-25 08:36:29 +00:00
|
|
|
/*
|
|
|
|
* Remove the bit-count field, which is between the
|
|
|
|
* first and second \t.
|
|
|
|
*/
|
|
|
|
int outpos;
|
|
|
|
pos = 0;
|
|
|
|
while (listentry[pos] && listentry[pos] != '\t')
|
|
|
|
pos++;
|
|
|
|
outpos = pos;
|
|
|
|
pos++;
|
|
|
|
while (listentry[pos] && listentry[pos] != '\t')
|
|
|
|
pos++;
|
|
|
|
while (1) {
|
|
|
|
if ((listentry[outpos] = listentry[pos]) == '\0')
|
|
|
|
break;
|
|
|
|
outpos++;
|
|
|
|
pos++;
|
|
|
|
}
|
|
|
|
}
|
2013-07-22 07:11:35 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
SendDlgItemMessage(keylist, 100, LB_ADDSTRING, 0,
|
|
|
|
(LPARAM) listentry);
|
2013-07-22 07:11:35 +00:00
|
|
|
sfree(listentry);
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
|
|
|
SendDlgItemMessage(keylist, 100, LB_SETCURSEL, (WPARAM) - 1, 0);
|
2000-09-26 13:18:43 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-05-11 14:06:25 +00:00
|
|
|
static void win_add_keyfile(Filename *filename)
|
|
|
|
{
|
|
|
|
char *err;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try loading the key without a passphrase. (Or rather, without a
|
|
|
|
* _new_ passphrase; pageant_add_keyfile will take care of trying
|
|
|
|
* all the passphrases we've already stored.)
|
|
|
|
*/
|
2020-02-08 17:28:46 +00:00
|
|
|
ret = pageant_add_keyfile(filename, NULL, &err, false);
|
2015-05-11 14:06:25 +00:00
|
|
|
if (ret == PAGEANT_ACTION_OK) {
|
|
|
|
goto done;
|
|
|
|
} else if (ret == PAGEANT_ACTION_FAILURE) {
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* OK, a passphrase is needed, and we've been given the key
|
|
|
|
* comment to use in the passphrase prompt.
|
|
|
|
*/
|
|
|
|
while (1) {
|
2015-08-11 12:27:48 +00:00
|
|
|
INT_PTR dlgret;
|
2015-05-11 14:06:25 +00:00
|
|
|
struct PassphraseProcStruct pps;
|
2020-03-21 15:59:51 +00:00
|
|
|
pps.modal = true;
|
|
|
|
pps.dlgid = NULL;
|
|
|
|
pps.passphrase = NULL;
|
2015-05-11 14:06:25 +00:00
|
|
|
pps.comment = err;
|
|
|
|
dlgret = DialogBoxParam(hinst, MAKEINTRESOURCE(210),
|
|
|
|
NULL, PassphraseProc, (LPARAM) &pps);
|
2020-03-21 15:59:51 +00:00
|
|
|
modal_passphrase_hwnd = NULL;
|
2015-05-11 14:06:25 +00:00
|
|
|
|
2020-03-21 15:59:51 +00:00
|
|
|
if (!dlgret) {
|
|
|
|
burnstr(pps.passphrase);
|
2019-09-08 19:29:00 +00:00
|
|
|
goto done; /* operation cancelled */
|
2020-03-21 15:59:51 +00:00
|
|
|
}
|
2015-05-11 14:06:25 +00:00
|
|
|
|
2015-10-18 19:22:05 +00:00
|
|
|
sfree(err);
|
|
|
|
|
2020-03-21 15:59:51 +00:00
|
|
|
assert(pps.passphrase != NULL);
|
|
|
|
|
|
|
|
ret = pageant_add_keyfile(filename, pps.passphrase, &err, false);
|
|
|
|
burnstr(pps.passphrase);
|
2015-05-11 14:06:25 +00:00
|
|
|
|
|
|
|
if (ret == PAGEANT_ACTION_OK) {
|
|
|
|
goto done;
|
|
|
|
} else if (ret == PAGEANT_ACTION_FAILURE) {
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
error:
|
2020-02-02 10:00:43 +00:00
|
|
|
message_box(traywindow, err, APPNAME, MB_OK | MB_ICONERROR,
|
2015-05-11 14:06:25 +00:00
|
|
|
HELPCTXID(errors_cantloadkey));
|
|
|
|
done:
|
|
|
|
sfree(err);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2000-10-12 15:26:40 +00:00
|
|
|
/*
|
|
|
|
* Prompt for a key file to add, and add it.
|
|
|
|
*/
|
2001-05-06 14:35:20 +00:00
|
|
|
static void prompt_add_keyfile(void)
|
|
|
|
{
|
2000-10-12 15:26:40 +00:00
|
|
|
OPENFILENAME of;
|
2003-03-29 16:14:26 +00:00
|
|
|
char *filelist = snewn(8192, char);
|
2019-09-08 19:29:00 +00:00
|
|
|
|
2005-02-28 02:40:43 +00:00
|
|
|
if (!keypath) keypath = filereq_new();
|
2000-10-12 15:26:40 +00:00
|
|
|
memset(&of, 0, sizeof(of));
|
2020-02-02 10:00:43 +00:00
|
|
|
of.hwndOwner = traywindow;
|
2005-02-28 02:40:43 +00:00
|
|
|
of.lpstrFilter = FILTER_KEY_FILES;
|
2000-10-12 15:26:40 +00:00
|
|
|
of.lpstrCustomFilter = NULL;
|
|
|
|
of.nFilterIndex = 1;
|
2001-12-10 17:40:14 +00:00
|
|
|
of.lpstrFile = filelist;
|
|
|
|
*filelist = '\0';
|
2005-02-28 02:40:43 +00:00
|
|
|
of.nMaxFile = 8192;
|
2000-10-12 15:26:40 +00:00
|
|
|
of.lpstrFileTitle = NULL;
|
|
|
|
of.lpstrTitle = "Select Private Key File";
|
2001-12-10 17:40:14 +00:00
|
|
|
of.Flags = OFN_ALLOWMULTISELECT | OFN_EXPLORER;
|
2018-10-29 19:50:29 +00:00
|
|
|
if (request_file(keypath, &of, true, false)) {
|
2019-09-08 19:29:00 +00:00
|
|
|
if(strlen(filelist) > of.nFileOffset) {
|
|
|
|
/* Only one filename returned? */
|
2013-07-22 07:11:54 +00:00
|
|
|
Filename *fn = filename_from_str(filelist);
|
2019-09-08 19:29:00 +00:00
|
|
|
win_add_keyfile(fn);
|
2013-07-22 07:11:54 +00:00
|
|
|
filename_free(fn);
|
|
|
|
} else {
|
2019-09-08 19:29:00 +00:00
|
|
|
/* we are returned a bunch of strings, end to
|
|
|
|
* end. first string is the directory, the
|
|
|
|
* rest the filenames. terminated with an
|
|
|
|
* empty string.
|
|
|
|
*/
|
|
|
|
char *dir = filelist;
|
|
|
|
char *filewalker = filelist + strlen(dir) + 1;
|
|
|
|
while (*filewalker != '\0') {
|
Make dupcat() into a variadic macro.
Up until now, it's been a variadic _function_, whose argument list
consists of 'const char *' ASCIZ strings to concatenate, terminated by
one containing a null pointer. Now, that function is dupcat_fn(), and
it's wrapped by a C99 variadic _macro_ called dupcat(), which
automatically suffixes the null-pointer terminating argument.
This has three benefits. Firstly, it's just less effort at every call
site. Secondly, it protects against the risk of accidentally leaving
off the NULL, causing arbitrary words of stack memory to be
dereferenced as char pointers. And thirdly, it protects against the
more subtle risk of writing a bare 'NULL' as the terminating argument,
instead of casting it explicitly to a pointer. That last one is
necessary because C permits the macro NULL to expand to an integer
constant such as 0, so NULL by itself may not have pointer type, and
worse, it may not be marshalled in a variadic argument list in the
same way as a pointer. (For example, on a 64-bit machine it might only
occupy 32 bits. And yet, on another 64-bit platform, it might work
just fine, so that you don't notice the mistake!)
I was inspired to do this by happening to notice one of those bare
NULL terminators, and thinking I'd better check if there were any
more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
|
|
|
char *filename = dupcat(dir, "\\", filewalker);
|
2013-07-22 07:11:54 +00:00
|
|
|
Filename *fn = filename_from_str(filename);
|
2019-09-08 19:29:00 +00:00
|
|
|
win_add_keyfile(fn);
|
2013-07-22 07:11:54 +00:00
|
|
|
filename_free(fn);
|
2019-09-08 19:29:00 +00:00
|
|
|
sfree(filename);
|
|
|
|
filewalker += strlen(filewalker) + 1;
|
|
|
|
}
|
|
|
|
}
|
2001-12-10 17:40:14 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
keylist_update();
|
|
|
|
pageant_forget_passphrases();
|
2000-10-12 15:26:40 +00:00
|
|
|
}
|
2001-12-10 17:40:14 +00:00
|
|
|
sfree(filelist);
|
2000-10-12 15:26:40 +00:00
|
|
|
}
|
|
|
|
|
2000-09-14 15:02:50 +00:00
|
|
|
/*
|
|
|
|
* Dialog-box function for the key list box.
|
|
|
|
*/
|
2015-08-11 12:22:09 +00:00
|
|
|
static INT_PTR CALLBACK KeyListProc(HWND hwnd, UINT msg,
|
2019-09-08 19:29:00 +00:00
|
|
|
WPARAM wParam, LPARAM lParam)
|
2001-05-06 14:35:20 +00:00
|
|
|
{
|
2019-01-04 06:51:44 +00:00
|
|
|
RSAKey *rkey;
|
|
|
|
ssh2_userkey *skey;
|
2000-09-14 15:02:50 +00:00
|
|
|
|
|
|
|
switch (msg) {
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
case WM_INITDIALOG: {
|
2019-09-08 19:29:00 +00:00
|
|
|
/*
|
|
|
|
* Centre the window.
|
|
|
|
*/
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
RECT rs, rd;
|
|
|
|
HWND hw;
|
|
|
|
|
|
|
|
hw = GetDesktopWindow();
|
|
|
|
if (GetWindowRect(hw, &rs) && GetWindowRect(hwnd, &rd))
|
|
|
|
MoveWindow(hwnd,
|
|
|
|
(rs.right + rs.left + rd.left - rd.right) / 2,
|
|
|
|
(rs.bottom + rs.top + rd.top - rd.bottom) / 2,
|
|
|
|
rd.right - rd.left, rd.bottom - rd.top, true);
|
2001-03-03 15:31:35 +00:00
|
|
|
|
2006-12-17 11:16:07 +00:00
|
|
|
if (has_help())
|
2005-05-21 14:16:43 +00:00
|
|
|
SetWindowLongPtr(hwnd, GWL_EXSTYLE,
|
2019-09-08 19:29:00 +00:00
|
|
|
GetWindowLongPtr(hwnd, GWL_EXSTYLE) |
|
|
|
|
WS_EX_CONTEXTHELP);
|
2001-12-11 18:48:29 +00:00
|
|
|
else {
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
HWND item = GetDlgItem(hwnd, 103); /* the Help button */
|
|
|
|
if (item)
|
|
|
|
DestroyWindow(item);
|
2001-12-11 18:48:29 +00:00
|
|
|
}
|
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
keylist = hwnd;
|
|
|
|
{
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
static int tabs[] = { 35, 75, 250 };
|
|
|
|
SendDlgItemMessage(hwnd, 100, LB_SETTABSTOPS,
|
|
|
|
sizeof(tabs) / sizeof(*tabs),
|
|
|
|
(LPARAM) tabs);
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
|
|
|
keylist_update();
|
|
|
|
return 0;
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
}
|
2000-09-14 15:02:50 +00:00
|
|
|
case WM_COMMAND:
|
2019-09-08 19:29:00 +00:00
|
|
|
switch (LOWORD(wParam)) {
|
|
|
|
case IDOK:
|
|
|
|
case IDCANCEL:
|
|
|
|
keylist = NULL;
|
|
|
|
DestroyWindow(hwnd);
|
|
|
|
return 0;
|
|
|
|
case 101: /* add key */
|
|
|
|
if (HIWORD(wParam) == BN_CLICKED ||
|
|
|
|
HIWORD(wParam) == BN_DOUBLECLICKED) {
|
2020-03-21 15:59:51 +00:00
|
|
|
if (modal_passphrase_hwnd) {
|
2019-09-08 19:29:00 +00:00
|
|
|
MessageBeep(MB_ICONERROR);
|
2020-03-21 15:59:51 +00:00
|
|
|
SetForegroundWindow(modal_passphrase_hwnd);
|
2019-09-08 19:29:00 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
prompt_add_keyfile();
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
case 102: /* remove key */
|
|
|
|
if (HIWORD(wParam) == BN_CLICKED ||
|
|
|
|
HIWORD(wParam) == BN_DOUBLECLICKED) {
|
|
|
|
int i;
|
|
|
|
int rCount, sCount;
|
|
|
|
int *selectedArray;
|
|
|
|
|
|
|
|
/* our counter within the array of selected items */
|
|
|
|
int itemNum;
|
|
|
|
|
|
|
|
/* get the number of items selected in the list */
|
|
|
|
int numSelected =
|
|
|
|
SendDlgItemMessage(hwnd, 100, LB_GETSELCOUNT, 0, 0);
|
|
|
|
|
|
|
|
/* none selected? that was silly */
|
|
|
|
if (numSelected == 0) {
|
|
|
|
MessageBeep(0);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* get item indices in an array */
|
|
|
|
selectedArray = snewn(numSelected, int);
|
|
|
|
SendDlgItemMessage(hwnd, 100, LB_GETSELITEMS,
|
|
|
|
numSelected, (WPARAM)selectedArray);
|
|
|
|
|
|
|
|
itemNum = numSelected - 1;
|
|
|
|
rCount = pageant_count_ssh1_keys();
|
|
|
|
sCount = pageant_count_ssh2_keys();
|
|
|
|
|
|
|
|
/* go through the non-rsakeys until we've covered them all,
|
|
|
|
* and/or we're out of selected items to check. note that
|
|
|
|
* we go *backwards*, to avoid complications from deleting
|
|
|
|
* things hence altering the offset of subsequent items
|
|
|
|
*/
|
2015-05-05 19:16:19 +00:00
|
|
|
for (i = sCount - 1; (itemNum >= 0) && (i >= 0); i--) {
|
|
|
|
skey = pageant_nth_ssh2_key(i);
|
2019-09-08 19:29:00 +00:00
|
|
|
|
2015-05-05 19:16:19 +00:00
|
|
|
if (selectedArray[itemNum] == rCount + i) {
|
|
|
|
pageant_delete_ssh2_key(skey);
|
2018-06-03 11:58:05 +00:00
|
|
|
ssh_key_free(skey->key);
|
2015-05-05 19:16:19 +00:00
|
|
|
sfree(skey);
|
|
|
|
itemNum--;
|
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* do the same for the rsa keys */
|
|
|
|
for (i = rCount - 1; (itemNum >= 0) && (i >= 0); i--) {
|
2015-05-05 19:16:19 +00:00
|
|
|
rkey = pageant_nth_ssh1_key(i);
|
|
|
|
|
|
|
|
if(selectedArray[itemNum] == i) {
|
|
|
|
pageant_delete_ssh1_key(rkey);
|
|
|
|
freersakey(rkey);
|
|
|
|
sfree(rkey);
|
|
|
|
itemNum--;
|
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
2001-12-10 17:40:14 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
sfree(selectedArray);
|
|
|
|
keylist_update();
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
case 103: /* help */
|
2001-12-11 18:48:29 +00:00
|
|
|
if (HIWORD(wParam) == BN_CLICKED ||
|
|
|
|
HIWORD(wParam) == BN_DOUBLECLICKED) {
|
2019-09-08 19:29:00 +00:00
|
|
|
launch_help(hwnd, WINHELP_CTX_pageant_general);
|
2001-12-11 18:48:29 +00:00
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 0;
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
case WM_HELP: {
|
|
|
|
int id = ((LPHELPINFO)lParam)->iCtrlId;
|
|
|
|
const char *topic = NULL;
|
|
|
|
switch (id) {
|
|
|
|
case 100: topic = WINHELP_CTX_pageant_keylist; break;
|
|
|
|
case 101: topic = WINHELP_CTX_pageant_addkey; break;
|
|
|
|
case 102: topic = WINHELP_CTX_pageant_remkey; break;
|
|
|
|
}
|
|
|
|
if (topic) {
|
|
|
|
launch_help(hwnd, topic);
|
|
|
|
} else {
|
|
|
|
MessageBeep(0);
|
2001-12-11 18:48:29 +00:00
|
|
|
}
|
|
|
|
break;
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
}
|
2000-09-14 15:02:50 +00:00
|
|
|
case WM_CLOSE:
|
2019-09-08 19:29:00 +00:00
|
|
|
keylist = NULL;
|
|
|
|
DestroyWindow(hwnd);
|
|
|
|
return 0;
|
2000-09-14 15:02:50 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2001-09-25 20:05:06 +00:00
|
|
|
/* Set up a system tray icon */
|
|
|
|
static BOOL AddTrayIcon(HWND hwnd)
|
|
|
|
{
|
|
|
|
BOOL res;
|
|
|
|
NOTIFYICONDATA tnid;
|
|
|
|
HICON hicon;
|
|
|
|
|
|
|
|
#ifdef NIM_SETVERSION
|
|
|
|
tnid.uVersion = 0;
|
|
|
|
res = Shell_NotifyIcon(NIM_SETVERSION, &tnid);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
tnid.cbSize = sizeof(NOTIFYICONDATA);
|
|
|
|
tnid.hWnd = hwnd;
|
2019-09-08 19:29:00 +00:00
|
|
|
tnid.uID = 1; /* unique within this systray use */
|
2001-09-25 20:05:06 +00:00
|
|
|
tnid.uFlags = NIF_MESSAGE | NIF_ICON | NIF_TIP;
|
|
|
|
tnid.uCallbackMessage = WM_SYSTRAY;
|
2005-03-01 01:16:57 +00:00
|
|
|
tnid.hIcon = hicon = LoadIcon(hinst, MAKEINTRESOURCE(201));
|
2001-09-25 20:05:06 +00:00
|
|
|
strcpy(tnid.szTip, "Pageant (PuTTY authentication agent)");
|
|
|
|
|
|
|
|
res = Shell_NotifyIcon(NIM_ADD, &tnid);
|
|
|
|
|
|
|
|
if (hicon) DestroyIcon(hicon);
|
2019-09-08 19:29:00 +00:00
|
|
|
|
2001-09-25 20:05:06 +00:00
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2002-03-27 20:30:57 +00:00
|
|
|
/* Update the saved-sessions menu. */
|
|
|
|
static void update_sessions(void)
|
|
|
|
{
|
|
|
|
int num_entries;
|
|
|
|
HKEY hkey;
|
|
|
|
TCHAR buf[MAX_PATH + 1];
|
|
|
|
MENUITEMINFO mii;
|
Rework mungestr() and unmungestr().
For a start, they now have different names on Windows and Unix,
reflecting their different roles: on Windows they apply escaping to
any string that's going to be used as a registry key (be it a session
name, or a host name for host key storage), whereas on Unix they're
for constructing saved-session file names in particular (and also
handle the special case of filling in "Default Settings" for NULL).
Also, they now produce output by writing to a strbuf, which simplifies
a lot of the call sites. In particular, the strbuf output idiom is
passed on to enum_settings_next, which is especially nice because its
only actual caller was doing an ad-hoc realloc loop that I can now get
rid of completely.
Thirdly, on Windows they're centralised into winmisc.c instead of
living in winstore.c, because that way Pageant can use the unescape
function too. (It was spotting the duplication there that made me
think of doing this in the first place, but once I'd started, I had to
keep unravelling the thread...)
2018-11-03 08:58:41 +00:00
|
|
|
strbuf *sb;
|
2002-03-27 20:30:57 +00:00
|
|
|
|
|
|
|
int index_key, index_menu;
|
|
|
|
|
|
|
|
if (!putty_path)
|
2019-09-08 19:29:00 +00:00
|
|
|
return;
|
2002-03-27 20:30:57 +00:00
|
|
|
|
|
|
|
if(ERROR_SUCCESS != RegOpenKey(HKEY_CURRENT_USER, PUTTY_REGKEY, &hkey))
|
2019-09-08 19:29:00 +00:00
|
|
|
return;
|
2002-03-27 20:30:57 +00:00
|
|
|
|
|
|
|
for(num_entries = GetMenuItemCount(session_menu);
|
2019-09-08 19:29:00 +00:00
|
|
|
num_entries > initial_menuitems_count;
|
|
|
|
num_entries--)
|
|
|
|
RemoveMenu(session_menu, 0, MF_BYPOSITION);
|
2002-03-27 20:30:57 +00:00
|
|
|
|
|
|
|
index_key = 0;
|
|
|
|
index_menu = 0;
|
|
|
|
|
Rework mungestr() and unmungestr().
For a start, they now have different names on Windows and Unix,
reflecting their different roles: on Windows they apply escaping to
any string that's going to be used as a registry key (be it a session
name, or a host name for host key storage), whereas on Unix they're
for constructing saved-session file names in particular (and also
handle the special case of filling in "Default Settings" for NULL).
Also, they now produce output by writing to a strbuf, which simplifies
a lot of the call sites. In particular, the strbuf output idiom is
passed on to enum_settings_next, which is especially nice because its
only actual caller was doing an ad-hoc realloc loop that I can now get
rid of completely.
Thirdly, on Windows they're centralised into winmisc.c instead of
living in winstore.c, because that way Pageant can use the unescape
function too. (It was spotting the duplication there that made me
think of doing this in the first place, but once I'd started, I had to
keep unravelling the thread...)
2018-11-03 08:58:41 +00:00
|
|
|
sb = strbuf_new();
|
2002-03-27 20:30:57 +00:00
|
|
|
while(ERROR_SUCCESS == RegEnumKey(hkey, index_key, buf, MAX_PATH)) {
|
2019-09-08 19:29:00 +00:00
|
|
|
if(strcmp(buf, PUTTY_DEFAULT) != 0) {
|
2020-01-21 20:16:28 +00:00
|
|
|
strbuf_clear(sb);
|
Rework mungestr() and unmungestr().
For a start, they now have different names on Windows and Unix,
reflecting their different roles: on Windows they apply escaping to
any string that's going to be used as a registry key (be it a session
name, or a host name for host key storage), whereas on Unix they're
for constructing saved-session file names in particular (and also
handle the special case of filling in "Default Settings" for NULL).
Also, they now produce output by writing to a strbuf, which simplifies
a lot of the call sites. In particular, the strbuf output idiom is
passed on to enum_settings_next, which is especially nice because its
only actual caller was doing an ad-hoc realloc loop that I can now get
rid of completely.
Thirdly, on Windows they're centralised into winmisc.c instead of
living in winstore.c, because that way Pageant can use the unescape
function too. (It was spotting the duplication there that made me
think of doing this in the first place, but once I'd started, I had to
keep unravelling the thread...)
2018-11-03 08:58:41 +00:00
|
|
|
unescape_registry_key(buf, sb);
|
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
memset(&mii, 0, sizeof(mii));
|
|
|
|
mii.cbSize = sizeof(mii);
|
|
|
|
mii.fMask = MIIM_TYPE | MIIM_STATE | MIIM_ID;
|
|
|
|
mii.fType = MFT_STRING;
|
|
|
|
mii.fState = MFS_ENABLED;
|
|
|
|
mii.wID = (index_menu * 16) + IDM_SESSIONS_BASE;
|
|
|
|
mii.dwTypeData = sb->s;
|
|
|
|
InsertMenuItem(session_menu, index_menu, true, &mii);
|
|
|
|
index_menu++;
|
|
|
|
}
|
|
|
|
index_key++;
|
2002-03-27 20:30:57 +00:00
|
|
|
}
|
Rework mungestr() and unmungestr().
For a start, they now have different names on Windows and Unix,
reflecting their different roles: on Windows they apply escaping to
any string that's going to be used as a registry key (be it a session
name, or a host name for host key storage), whereas on Unix they're
for constructing saved-session file names in particular (and also
handle the special case of filling in "Default Settings" for NULL).
Also, they now produce output by writing to a strbuf, which simplifies
a lot of the call sites. In particular, the strbuf output idiom is
passed on to enum_settings_next, which is especially nice because its
only actual caller was doing an ad-hoc realloc loop that I can now get
rid of completely.
Thirdly, on Windows they're centralised into winmisc.c instead of
living in winstore.c, because that way Pageant can use the unescape
function too. (It was spotting the duplication there that made me
think of doing this in the first place, but once I'd started, I had to
keep unravelling the thread...)
2018-11-03 08:58:41 +00:00
|
|
|
strbuf_free(sb);
|
2002-03-27 20:30:57 +00:00
|
|
|
|
|
|
|
RegCloseKey(hkey);
|
|
|
|
|
|
|
|
if(index_menu == 0) {
|
2019-09-08 19:29:00 +00:00
|
|
|
mii.cbSize = sizeof(mii);
|
|
|
|
mii.fMask = MIIM_TYPE | MIIM_STATE;
|
|
|
|
mii.fType = MFT_STRING;
|
|
|
|
mii.fState = MFS_GRAYED;
|
|
|
|
mii.dwTypeData = _T("(No sessions)");
|
|
|
|
InsertMenuItem(session_menu, index_menu, true, &mii);
|
2002-03-27 20:30:57 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-08-13 14:48:36 +00:00
|
|
|
#ifndef NO_SECURITY
|
|
|
|
/*
|
|
|
|
* Versions of Pageant prior to 0.61 expected this SID on incoming
|
|
|
|
* communications. For backwards compatibility, and more particularly
|
|
|
|
* for compatibility with derived works of PuTTY still using the old
|
|
|
|
* Pageant client code, we accept it as an alternative to the one
|
|
|
|
* returned from get_user_sid() in winpgntc.c.
|
|
|
|
*/
|
|
|
|
PSID get_default_sid(void)
|
|
|
|
{
|
|
|
|
HANDLE proc = NULL;
|
|
|
|
DWORD sidlen;
|
|
|
|
PSECURITY_DESCRIPTOR psd = NULL;
|
|
|
|
PSID sid = NULL, copy = NULL, ret = NULL;
|
|
|
|
|
2018-10-29 19:50:29 +00:00
|
|
|
if ((proc = OpenProcess(MAXIMUM_ALLOWED, false,
|
2011-08-13 14:48:36 +00:00
|
|
|
GetCurrentProcessId())) == NULL)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
if (p_GetSecurityInfo(proc, SE_KERNEL_OBJECT, OWNER_SECURITY_INFORMATION,
|
|
|
|
&sid, NULL, NULL, NULL, &psd) != ERROR_SUCCESS)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
sidlen = GetLengthSid(sid);
|
|
|
|
|
|
|
|
copy = (PSID)smalloc(sidlen);
|
|
|
|
|
|
|
|
if (!CopySid(sidlen, copy, sid))
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
/* Success. Move sid into the return value slot, and null it out
|
|
|
|
* to stop the cleanup code freeing it. */
|
|
|
|
ret = copy;
|
|
|
|
copy = NULL;
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
if (proc != NULL)
|
|
|
|
CloseHandle(proc);
|
|
|
|
if (psd != NULL)
|
|
|
|
LocalFree(psd);
|
|
|
|
if (copy != NULL)
|
|
|
|
sfree(copy);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
struct WmCopydataTransaction {
|
|
|
|
char *length, *body;
|
|
|
|
size_t bodysize, bodylen;
|
|
|
|
HANDLE ev_msg_ready, ev_reply_ready;
|
|
|
|
} wmct;
|
2018-07-08 14:29:41 +00:00
|
|
|
|
Pageant: new asynchronous internal APIs.
This is a pure refactoring: no functional change expected.
This commit introduces two new small vtable-style APIs. One is
PageantClient, which identifies a particular client of the Pageant
'core' (meaning the code that handles each individual request). This
changes pageant_handle_msg into an asynchronous operation: you pass in
an agent request message and an identifier, and at some later point,
the got_response method in your PageantClient will be called with the
answer (and the same identifier, to allow you to match requests to
responses). The trait vtable also contains a logging system.
The main importance of PageantClient, and the reason why it has to
exist instead of just passing pageant_handle_msg a bare callback
function pointer and context parameter, is that it provides robustness
if a client stops existing while a request is still pending. You call
pageant_unregister_client, and any unfinished requests associated with
that client in the Pageant core will be cleaned up, so that you're
guaranteed that after the unregister operation, no stray callbacks
will happen with a stale pointer to that client.
The WM_COPYDATA interface of Windows Pageant is a direct client of
this API. The other client is PageantListener, the system that lives
in pageant.c and handles stream-based agent connections for both Unix
Pageant and the new Windows named-pipe IPC. More specifically, each
individual connection to the listening socket is a separate
PageantClient, which means that if a socket is closed abruptly or
suffers an OS error, that client can be unregistered and any pending
requests cancelled without disrupting other connections.
Users of PageantListener have a second client vtable they can use,
called PageantListenerClient. That contains _only_ logging facilities,
and at the moment, only Unix Pageant bothers to use it (and even that
only in debugging mode).
Finally, internally to the Pageant core, there's a new trait called
PageantAsyncOp which describes an agent request in the process of
being handled. But at the moment, it has only one trivial
implementation, which is handed the full response message already
constructed, and on the next toplevel callback, passes it back to the
PageantClient.
2020-01-25 17:24:28 +00:00
|
|
|
static struct PageantClient wmcpc;
|
|
|
|
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
static void wm_copydata_got_msg(void *vctx)
|
2018-07-08 14:29:41 +00:00
|
|
|
{
|
Pageant: new asynchronous internal APIs.
This is a pure refactoring: no functional change expected.
This commit introduces two new small vtable-style APIs. One is
PageantClient, which identifies a particular client of the Pageant
'core' (meaning the code that handles each individual request). This
changes pageant_handle_msg into an asynchronous operation: you pass in
an agent request message and an identifier, and at some later point,
the got_response method in your PageantClient will be called with the
answer (and the same identifier, to allow you to match requests to
responses). The trait vtable also contains a logging system.
The main importance of PageantClient, and the reason why it has to
exist instead of just passing pageant_handle_msg a bare callback
function pointer and context parameter, is that it provides robustness
if a client stops existing while a request is still pending. You call
pageant_unregister_client, and any unfinished requests associated with
that client in the Pageant core will be cleaned up, so that you're
guaranteed that after the unregister operation, no stray callbacks
will happen with a stale pointer to that client.
The WM_COPYDATA interface of Windows Pageant is a direct client of
this API. The other client is PageantListener, the system that lives
in pageant.c and handles stream-based agent connections for both Unix
Pageant and the new Windows named-pipe IPC. More specifically, each
individual connection to the listening socket is a separate
PageantClient, which means that if a socket is closed abruptly or
suffers an OS error, that client can be unregistered and any pending
requests cancelled without disrupting other connections.
Users of PageantListener have a second client vtable they can use,
called PageantListenerClient. That contains _only_ logging facilities,
and at the moment, only Unix Pageant bothers to use it (and even that
only in debugging mode).
Finally, internally to the Pageant core, there's a new trait called
PageantAsyncOp which describes an agent request in the process of
being handled. But at the moment, it has only one trivial
implementation, which is handed the full response message already
constructed, and on the next toplevel callback, passes it back to the
PageantClient.
2020-01-25 17:24:28 +00:00
|
|
|
pageant_handle_msg(&wmcpc, NULL, make_ptrlen(wmct.body, wmct.bodylen));
|
|
|
|
}
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
|
2020-01-26 12:45:30 +00:00
|
|
|
static void wm_copydata_got_response(
|
|
|
|
PageantClient *pc, PageantClientRequestId *reqid, ptrlen response)
|
Pageant: new asynchronous internal APIs.
This is a pure refactoring: no functional change expected.
This commit introduces two new small vtable-style APIs. One is
PageantClient, which identifies a particular client of the Pageant
'core' (meaning the code that handles each individual request). This
changes pageant_handle_msg into an asynchronous operation: you pass in
an agent request message and an identifier, and at some later point,
the got_response method in your PageantClient will be called with the
answer (and the same identifier, to allow you to match requests to
responses). The trait vtable also contains a logging system.
The main importance of PageantClient, and the reason why it has to
exist instead of just passing pageant_handle_msg a bare callback
function pointer and context parameter, is that it provides robustness
if a client stops existing while a request is still pending. You call
pageant_unregister_client, and any unfinished requests associated with
that client in the Pageant core will be cleaned up, so that you're
guaranteed that after the unregister operation, no stray callbacks
will happen with a stale pointer to that client.
The WM_COPYDATA interface of Windows Pageant is a direct client of
this API. The other client is PageantListener, the system that lives
in pageant.c and handles stream-based agent connections for both Unix
Pageant and the new Windows named-pipe IPC. More specifically, each
individual connection to the listening socket is a separate
PageantClient, which means that if a socket is closed abruptly or
suffers an OS error, that client can be unregistered and any pending
requests cancelled without disrupting other connections.
Users of PageantListener have a second client vtable they can use,
called PageantListenerClient. That contains _only_ logging facilities,
and at the moment, only Unix Pageant bothers to use it (and even that
only in debugging mode).
Finally, internally to the Pageant core, there's a new trait called
PageantAsyncOp which describes an agent request in the process of
being handled. But at the moment, it has only one trivial
implementation, which is handed the full response message already
constructed, and on the next toplevel callback, passes it back to the
PageantClient.
2020-01-25 17:24:28 +00:00
|
|
|
{
|
|
|
|
if (response.len > wmct.bodysize) {
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
/* Output would overflow message buffer. Replace with a
|
|
|
|
* failure message. */
|
Pageant: new asynchronous internal APIs.
This is a pure refactoring: no functional change expected.
This commit introduces two new small vtable-style APIs. One is
PageantClient, which identifies a particular client of the Pageant
'core' (meaning the code that handles each individual request). This
changes pageant_handle_msg into an asynchronous operation: you pass in
an agent request message and an identifier, and at some later point,
the got_response method in your PageantClient will be called with the
answer (and the same identifier, to allow you to match requests to
responses). The trait vtable also contains a logging system.
The main importance of PageantClient, and the reason why it has to
exist instead of just passing pageant_handle_msg a bare callback
function pointer and context parameter, is that it provides robustness
if a client stops existing while a request is still pending. You call
pageant_unregister_client, and any unfinished requests associated with
that client in the Pageant core will be cleaned up, so that you're
guaranteed that after the unregister operation, no stray callbacks
will happen with a stale pointer to that client.
The WM_COPYDATA interface of Windows Pageant is a direct client of
this API. The other client is PageantListener, the system that lives
in pageant.c and handles stream-based agent connections for both Unix
Pageant and the new Windows named-pipe IPC. More specifically, each
individual connection to the listening socket is a separate
PageantClient, which means that if a socket is closed abruptly or
suffers an OS error, that client can be unregistered and any pending
requests cancelled without disrupting other connections.
Users of PageantListener have a second client vtable they can use,
called PageantListenerClient. That contains _only_ logging facilities,
and at the moment, only Unix Pageant bothers to use it (and even that
only in debugging mode).
Finally, internally to the Pageant core, there's a new trait called
PageantAsyncOp which describes an agent request in the process of
being handled. But at the moment, it has only one trivial
implementation, which is handed the full response message already
constructed, and on the next toplevel callback, passes it back to the
PageantClient.
2020-01-25 17:24:28 +00:00
|
|
|
static const unsigned char failure[] = { SSH_AGENT_FAILURE };
|
|
|
|
response = make_ptrlen(failure, lenof(failure));
|
|
|
|
assert(response.len <= wmct.bodysize);
|
2018-07-08 14:29:41 +00:00
|
|
|
}
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
|
Pageant: new asynchronous internal APIs.
This is a pure refactoring: no functional change expected.
This commit introduces two new small vtable-style APIs. One is
PageantClient, which identifies a particular client of the Pageant
'core' (meaning the code that handles each individual request). This
changes pageant_handle_msg into an asynchronous operation: you pass in
an agent request message and an identifier, and at some later point,
the got_response method in your PageantClient will be called with the
answer (and the same identifier, to allow you to match requests to
responses). The trait vtable also contains a logging system.
The main importance of PageantClient, and the reason why it has to
exist instead of just passing pageant_handle_msg a bare callback
function pointer and context parameter, is that it provides robustness
if a client stops existing while a request is still pending. You call
pageant_unregister_client, and any unfinished requests associated with
that client in the Pageant core will be cleaned up, so that you're
guaranteed that after the unregister operation, no stray callbacks
will happen with a stale pointer to that client.
The WM_COPYDATA interface of Windows Pageant is a direct client of
this API. The other client is PageantListener, the system that lives
in pageant.c and handles stream-based agent connections for both Unix
Pageant and the new Windows named-pipe IPC. More specifically, each
individual connection to the listening socket is a separate
PageantClient, which means that if a socket is closed abruptly or
suffers an OS error, that client can be unregistered and any pending
requests cancelled without disrupting other connections.
Users of PageantListener have a second client vtable they can use,
called PageantListenerClient. That contains _only_ logging facilities,
and at the moment, only Unix Pageant bothers to use it (and even that
only in debugging mode).
Finally, internally to the Pageant core, there's a new trait called
PageantAsyncOp which describes an agent request in the process of
being handled. But at the moment, it has only one trivial
implementation, which is handed the full response message already
constructed, and on the next toplevel callback, passes it back to the
PageantClient.
2020-01-25 17:24:28 +00:00
|
|
|
PUT_32BIT_MSB_FIRST(wmct.length, response.len);
|
|
|
|
memcpy(wmct.body, response.ptr, response.len);
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
|
|
|
|
SetEvent(wmct.ev_reply_ready);
|
2018-07-08 14:29:41 +00:00
|
|
|
}
|
|
|
|
|
2020-03-21 15:59:51 +00:00
|
|
|
static bool ask_passphrase_common(PageantClientDialogId *dlgid,
|
|
|
|
const char *msg)
|
|
|
|
{
|
|
|
|
/* Pageant core should be serialising requests, so we never expect
|
|
|
|
* a passphrase prompt to exist already at this point */
|
|
|
|
assert(!nonmodal_passphrase_hwnd);
|
|
|
|
|
|
|
|
struct PassphraseProcStruct *pps = snew(struct PassphraseProcStruct);
|
|
|
|
pps->modal = false;
|
|
|
|
pps->dlgid = dlgid;
|
|
|
|
pps->passphrase = NULL;
|
|
|
|
pps->comment = msg;
|
|
|
|
|
|
|
|
nonmodal_passphrase_hwnd = CreateDialogParam(
|
|
|
|
hinst, MAKEINTRESOURCE(210), NULL, PassphraseProc, (LPARAM)pps);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2020-01-20 21:22:33 +00:00
|
|
|
static bool wm_copydata_ask_passphrase(
|
|
|
|
PageantClient *pc, PageantClientDialogId *dlgid, const char *msg)
|
|
|
|
{
|
2020-03-21 15:59:51 +00:00
|
|
|
return ask_passphrase_common(dlgid, msg);
|
2020-01-20 21:22:33 +00:00
|
|
|
}
|
|
|
|
|
Pageant: new asynchronous internal APIs.
This is a pure refactoring: no functional change expected.
This commit introduces two new small vtable-style APIs. One is
PageantClient, which identifies a particular client of the Pageant
'core' (meaning the code that handles each individual request). This
changes pageant_handle_msg into an asynchronous operation: you pass in
an agent request message and an identifier, and at some later point,
the got_response method in your PageantClient will be called with the
answer (and the same identifier, to allow you to match requests to
responses). The trait vtable also contains a logging system.
The main importance of PageantClient, and the reason why it has to
exist instead of just passing pageant_handle_msg a bare callback
function pointer and context parameter, is that it provides robustness
if a client stops existing while a request is still pending. You call
pageant_unregister_client, and any unfinished requests associated with
that client in the Pageant core will be cleaned up, so that you're
guaranteed that after the unregister operation, no stray callbacks
will happen with a stale pointer to that client.
The WM_COPYDATA interface of Windows Pageant is a direct client of
this API. The other client is PageantListener, the system that lives
in pageant.c and handles stream-based agent connections for both Unix
Pageant and the new Windows named-pipe IPC. More specifically, each
individual connection to the listening socket is a separate
PageantClient, which means that if a socket is closed abruptly or
suffers an OS error, that client can be unregistered and any pending
requests cancelled without disrupting other connections.
Users of PageantListener have a second client vtable they can use,
called PageantListenerClient. That contains _only_ logging facilities,
and at the moment, only Unix Pageant bothers to use it (and even that
only in debugging mode).
Finally, internally to the Pageant core, there's a new trait called
PageantAsyncOp which describes an agent request in the process of
being handled. But at the moment, it has only one trivial
implementation, which is handed the full response message already
constructed, and on the next toplevel callback, passes it back to the
PageantClient.
2020-01-25 17:24:28 +00:00
|
|
|
static const PageantClientVtable wmcpc_vtable = {
|
Change vtable defs to use C99 designated initialisers.
This is a sweeping change applied across the whole code base by a spot
of Emacs Lisp. Now, everywhere I declare a vtable filled with function
pointers (and the occasional const data member), all the members of
the vtable structure are initialised by name using the '.fieldname =
value' syntax introduced in C99.
We were already using this syntax for a handful of things in the new
key-generation progress report system, so it's not new to the code
base as a whole.
The advantage is that now, when a vtable only declares a subset of the
available fields, I can initialise the rest to NULL or zero just by
leaving them out. This is most dramatic in a couple of the outlying
vtables in things like psocks (which has a ConnectionLayerVtable
containing only one non-NULL method), but less dramatically, it means
that the new 'flags' field in BackendVtable can be completely left out
of every backend definition except for the SUPDUP one which defines it
to a nonzero value. Similarly, the test_for_upstream method only used
by SSH doesn't have to be mentioned in the rest of the backends;
network Plugs for listening sockets don't have to explicitly null out
'receive' and 'sent', and vice versa for 'accepting', and so on.
While I'm at it, I've normalised the declarations so they don't use
the unnecessarily verbose 'struct' keyword. Also a handful of them
weren't const; now they are.
2020-03-10 21:06:29 +00:00
|
|
|
.log = NULL, /* no logging in this client */
|
|
|
|
.got_response = wm_copydata_got_response,
|
|
|
|
.ask_passphrase = wm_copydata_ask_passphrase,
|
Pageant: new asynchronous internal APIs.
This is a pure refactoring: no functional change expected.
This commit introduces two new small vtable-style APIs. One is
PageantClient, which identifies a particular client of the Pageant
'core' (meaning the code that handles each individual request). This
changes pageant_handle_msg into an asynchronous operation: you pass in
an agent request message and an identifier, and at some later point,
the got_response method in your PageantClient will be called with the
answer (and the same identifier, to allow you to match requests to
responses). The trait vtable also contains a logging system.
The main importance of PageantClient, and the reason why it has to
exist instead of just passing pageant_handle_msg a bare callback
function pointer and context parameter, is that it provides robustness
if a client stops existing while a request is still pending. You call
pageant_unregister_client, and any unfinished requests associated with
that client in the Pageant core will be cleaned up, so that you're
guaranteed that after the unregister operation, no stray callbacks
will happen with a stale pointer to that client.
The WM_COPYDATA interface of Windows Pageant is a direct client of
this API. The other client is PageantListener, the system that lives
in pageant.c and handles stream-based agent connections for both Unix
Pageant and the new Windows named-pipe IPC. More specifically, each
individual connection to the listening socket is a separate
PageantClient, which means that if a socket is closed abruptly or
suffers an OS error, that client can be unregistered and any pending
requests cancelled without disrupting other connections.
Users of PageantListener have a second client vtable they can use,
called PageantListenerClient. That contains _only_ logging facilities,
and at the moment, only Unix Pageant bothers to use it (and even that
only in debugging mode).
Finally, internally to the Pageant core, there's a new trait called
PageantAsyncOp which describes an agent request in the process of
being handled. But at the moment, it has only one trivial
implementation, which is handed the full response message already
constructed, and on the next toplevel callback, passes it back to the
PageantClient.
2020-01-25 17:24:28 +00:00
|
|
|
};
|
|
|
|
|
2018-07-08 14:29:41 +00:00
|
|
|
static char *answer_filemapping_message(const char *mapname)
|
|
|
|
{
|
|
|
|
HANDLE maphandle = INVALID_HANDLE_VALUE;
|
|
|
|
void *mapaddr = NULL;
|
|
|
|
char *err = NULL;
|
winpgnt.c: handle arbitrarily large file mappings.
I heard recently that at least one third-party client of Pageant
exists, and that it's used to generate signatures to use with TLS
client certificates. Apparently the signature scheme is compatible,
but TLS tends to need signatures over more data than will fit in
AGENT_MAX_MSGLEN.
Before the BinarySink refactor in commit b6cbad89f, this was OK
because the Windows Pageant IPC didn't check the size of the _input_
message against AGENT_MAX_MSGLEN, only the output one. But then we
started checking both, so that third-party TLS client started failing.
Now we use VirtualQuery to find out the actual size of the file
mapping we've been passed, and our only requirement is that the input
and output messages should both fit in _that_. So TLS should work
again, and also, other clients should be able to retrieve longer lists
of public keys if they pass a larger file mapping.
One side effect of this change is that Pageant's reply message is now
written directly into the shared-memory region. Previously, it was
written into a separate buffer and then memcpy()ed over after
pageant_handle_msg returned, but now the buffer is variable-size, it
seems to me to make more sense to avoid that extra not-entirely
controlled malloc. So I've done one very small reordering of
statements in the cross-platform pageant_handle_msg(), which fixes the
only case I could find where that function started writing its output
before it had finished using the contents of the input buffer.
2018-07-08 15:46:32 +00:00
|
|
|
size_t mapsize;
|
2018-07-08 14:29:41 +00:00
|
|
|
unsigned msglen;
|
|
|
|
|
|
|
|
#ifndef NO_SECURITY
|
|
|
|
PSID mapsid = NULL;
|
|
|
|
PSID expectedsid = NULL;
|
|
|
|
PSID expectedsid_bc = NULL;
|
|
|
|
PSECURITY_DESCRIPTOR psd = NULL;
|
|
|
|
#endif
|
|
|
|
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
wmct.length = wmct.body = NULL;
|
winpgnt.c: handle arbitrarily large file mappings.
I heard recently that at least one third-party client of Pageant
exists, and that it's used to generate signatures to use with TLS
client certificates. Apparently the signature scheme is compatible,
but TLS tends to need signatures over more data than will fit in
AGENT_MAX_MSGLEN.
Before the BinarySink refactor in commit b6cbad89f, this was OK
because the Windows Pageant IPC didn't check the size of the _input_
message against AGENT_MAX_MSGLEN, only the output one. But then we
started checking both, so that third-party TLS client started failing.
Now we use VirtualQuery to find out the actual size of the file
mapping we've been passed, and our only requirement is that the input
and output messages should both fit in _that_. So TLS should work
again, and also, other clients should be able to retrieve longer lists
of public keys if they pass a larger file mapping.
One side effect of this change is that Pageant's reply message is now
written directly into the shared-memory region. Previously, it was
written into a separate buffer and then memcpy()ed over after
pageant_handle_msg returned, but now the buffer is variable-size, it
seems to me to make more sense to avoid that extra not-entirely
controlled malloc. So I've done one very small reordering of
statements in the cross-platform pageant_handle_msg(), which fixes the
only case I could find where that function started writing its output
before it had finished using the contents of the input buffer.
2018-07-08 15:46:32 +00:00
|
|
|
|
2018-07-08 14:29:41 +00:00
|
|
|
#ifdef DEBUG_IPC
|
Start using C99 variadic macros.
In the past, I've had a lot of macros which you call with double
parentheses, along the lines of debug(("format string", params)), so
that the inner parens protect the commas and permit the macro to treat
the whole printf-style argument list as one macro argument.
That's all very well, but it's a bit inconvenient (it doesn't leave
you any way to implement such a macro by prepending another argument
to the list), and now this code base's rules allow C99isms, I can
switch all those macros to using a single pair of parens, using the
C99 ability to say '...' in the parameter list of the #define and get
at the corresponding suffix of the arguments as __VA_ARGS__.
So I'm doing it. I've made the following printf-style macros variadic:
bpp_logevent, ppl_logevent, ppl_printf and debug.
While I'm here, I've also fixed up a collection of conditioned-out
calls to debug() in the Windows front end which were clearly expecting
a macro with a different calling syntax, because they had an integer
parameter first. If I ever have a need to condition those back in,
they should actually work now.
2018-12-08 20:32:31 +00:00
|
|
|
debug("mapname = \"%s\"\n", mapname);
|
2018-07-08 14:29:41 +00:00
|
|
|
#endif
|
|
|
|
|
2018-10-29 19:50:29 +00:00
|
|
|
maphandle = OpenFileMapping(FILE_MAP_ALL_ACCESS, false, mapname);
|
2018-07-08 14:29:41 +00:00
|
|
|
if (maphandle == NULL || maphandle == INVALID_HANDLE_VALUE) {
|
|
|
|
err = dupprintf("OpenFileMapping(\"%s\"): %s",
|
|
|
|
mapname, win_strerror(GetLastError()));
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef DEBUG_IPC
|
Start using C99 variadic macros.
In the past, I've had a lot of macros which you call with double
parentheses, along the lines of debug(("format string", params)), so
that the inner parens protect the commas and permit the macro to treat
the whole printf-style argument list as one macro argument.
That's all very well, but it's a bit inconvenient (it doesn't leave
you any way to implement such a macro by prepending another argument
to the list), and now this code base's rules allow C99isms, I can
switch all those macros to using a single pair of parens, using the
C99 ability to say '...' in the parameter list of the #define and get
at the corresponding suffix of the arguments as __VA_ARGS__.
So I'm doing it. I've made the following printf-style macros variadic:
bpp_logevent, ppl_logevent, ppl_printf and debug.
While I'm here, I've also fixed up a collection of conditioned-out
calls to debug() in the Windows front end which were clearly expecting
a macro with a different calling syntax, because they had an integer
parameter first. If I ever have a need to condition those back in,
they should actually work now.
2018-12-08 20:32:31 +00:00
|
|
|
debug("maphandle = %p\n", maphandle);
|
2018-07-08 14:29:41 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef NO_SECURITY
|
|
|
|
if (has_security) {
|
|
|
|
DWORD retd;
|
|
|
|
|
|
|
|
if ((expectedsid = get_user_sid()) == NULL) {
|
|
|
|
err = dupstr("unable to get user SID");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((expectedsid_bc = get_default_sid()) == NULL) {
|
|
|
|
err = dupstr("unable to get default SID");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((retd = p_GetSecurityInfo(
|
|
|
|
maphandle, SE_KERNEL_OBJECT, OWNER_SECURITY_INFORMATION,
|
|
|
|
&mapsid, NULL, NULL, NULL, &psd) != ERROR_SUCCESS)) {
|
|
|
|
err = dupprintf("unable to get owner of file mapping: "
|
|
|
|
"GetSecurityInfo returned: %s",
|
|
|
|
win_strerror(retd));
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef DEBUG_IPC
|
|
|
|
{
|
|
|
|
LPTSTR ours, ours2, theirs;
|
|
|
|
ConvertSidToStringSid(mapsid, &theirs);
|
|
|
|
ConvertSidToStringSid(expectedsid, &ours);
|
|
|
|
ConvertSidToStringSid(expectedsid_bc, &ours2);
|
Start using C99 variadic macros.
In the past, I've had a lot of macros which you call with double
parentheses, along the lines of debug(("format string", params)), so
that the inner parens protect the commas and permit the macro to treat
the whole printf-style argument list as one macro argument.
That's all very well, but it's a bit inconvenient (it doesn't leave
you any way to implement such a macro by prepending another argument
to the list), and now this code base's rules allow C99isms, I can
switch all those macros to using a single pair of parens, using the
C99 ability to say '...' in the parameter list of the #define and get
at the corresponding suffix of the arguments as __VA_ARGS__.
So I'm doing it. I've made the following printf-style macros variadic:
bpp_logevent, ppl_logevent, ppl_printf and debug.
While I'm here, I've also fixed up a collection of conditioned-out
calls to debug() in the Windows front end which were clearly expecting
a macro with a different calling syntax, because they had an integer
parameter first. If I ever have a need to condition those back in,
they should actually work now.
2018-12-08 20:32:31 +00:00
|
|
|
debug("got sids:\n oursnew=%s\n oursold=%s\n"
|
|
|
|
" theirs=%s\n", ours, ours2, theirs);
|
2018-07-08 14:29:41 +00:00
|
|
|
LocalFree(ours);
|
|
|
|
LocalFree(ours2);
|
|
|
|
LocalFree(theirs);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
if (!EqualSid(mapsid, expectedsid) &&
|
|
|
|
!EqualSid(mapsid, expectedsid_bc)) {
|
|
|
|
err = dupstr("wrong owning SID of file mapping");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
} else
|
|
|
|
#endif /* NO_SECURITY */
|
|
|
|
{
|
|
|
|
#ifdef DEBUG_IPC
|
Start using C99 variadic macros.
In the past, I've had a lot of macros which you call with double
parentheses, along the lines of debug(("format string", params)), so
that the inner parens protect the commas and permit the macro to treat
the whole printf-style argument list as one macro argument.
That's all very well, but it's a bit inconvenient (it doesn't leave
you any way to implement such a macro by prepending another argument
to the list), and now this code base's rules allow C99isms, I can
switch all those macros to using a single pair of parens, using the
C99 ability to say '...' in the parameter list of the #define and get
at the corresponding suffix of the arguments as __VA_ARGS__.
So I'm doing it. I've made the following printf-style macros variadic:
bpp_logevent, ppl_logevent, ppl_printf and debug.
While I'm here, I've also fixed up a collection of conditioned-out
calls to debug() in the Windows front end which were clearly expecting
a macro with a different calling syntax, because they had an integer
parameter first. If I ever have a need to condition those back in,
they should actually work now.
2018-12-08 20:32:31 +00:00
|
|
|
debug("security APIs not present\n");
|
2018-07-08 14:29:41 +00:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
mapaddr = MapViewOfFile(maphandle, FILE_MAP_WRITE, 0, 0, 0);
|
|
|
|
if (!mapaddr) {
|
|
|
|
err = dupprintf("unable to obtain view of file mapping: %s",
|
|
|
|
win_strerror(GetLastError()));
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef DEBUG_IPC
|
Start using C99 variadic macros.
In the past, I've had a lot of macros which you call with double
parentheses, along the lines of debug(("format string", params)), so
that the inner parens protect the commas and permit the macro to treat
the whole printf-style argument list as one macro argument.
That's all very well, but it's a bit inconvenient (it doesn't leave
you any way to implement such a macro by prepending another argument
to the list), and now this code base's rules allow C99isms, I can
switch all those macros to using a single pair of parens, using the
C99 ability to say '...' in the parameter list of the #define and get
at the corresponding suffix of the arguments as __VA_ARGS__.
So I'm doing it. I've made the following printf-style macros variadic:
bpp_logevent, ppl_logevent, ppl_printf and debug.
While I'm here, I've also fixed up a collection of conditioned-out
calls to debug() in the Windows front end which were clearly expecting
a macro with a different calling syntax, because they had an integer
parameter first. If I ever have a need to condition those back in,
they should actually work now.
2018-12-08 20:32:31 +00:00
|
|
|
debug("mapped address = %p\n", mapaddr);
|
2018-07-08 14:29:41 +00:00
|
|
|
#endif
|
|
|
|
|
winpgnt.c: handle arbitrarily large file mappings.
I heard recently that at least one third-party client of Pageant
exists, and that it's used to generate signatures to use with TLS
client certificates. Apparently the signature scheme is compatible,
but TLS tends to need signatures over more data than will fit in
AGENT_MAX_MSGLEN.
Before the BinarySink refactor in commit b6cbad89f, this was OK
because the Windows Pageant IPC didn't check the size of the _input_
message against AGENT_MAX_MSGLEN, only the output one. But then we
started checking both, so that third-party TLS client started failing.
Now we use VirtualQuery to find out the actual size of the file
mapping we've been passed, and our only requirement is that the input
and output messages should both fit in _that_. So TLS should work
again, and also, other clients should be able to retrieve longer lists
of public keys if they pass a larger file mapping.
One side effect of this change is that Pageant's reply message is now
written directly into the shared-memory region. Previously, it was
written into a separate buffer and then memcpy()ed over after
pageant_handle_msg returned, but now the buffer is variable-size, it
seems to me to make more sense to avoid that extra not-entirely
controlled malloc. So I've done one very small reordering of
statements in the cross-platform pageant_handle_msg(), which fixes the
only case I could find where that function started writing its output
before it had finished using the contents of the input buffer.
2018-07-08 15:46:32 +00:00
|
|
|
{
|
|
|
|
MEMORY_BASIC_INFORMATION mbi;
|
|
|
|
size_t mbiSize = VirtualQuery(mapaddr, &mbi, sizeof(mbi));
|
|
|
|
if (mbiSize == 0) {
|
|
|
|
err = dupprintf("unable to query view of file mapping: %s",
|
|
|
|
win_strerror(GetLastError()));
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
if (mbiSize < (offsetof(MEMORY_BASIC_INFORMATION, RegionSize) +
|
|
|
|
sizeof(mbi.RegionSize))) {
|
|
|
|
err = dupstr("VirtualQuery returned too little data to get "
|
|
|
|
"region size");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
mapsize = mbi.RegionSize;
|
|
|
|
}
|
|
|
|
#ifdef DEBUG_IPC
|
2020-01-26 10:59:07 +00:00
|
|
|
debug("region size = %"SIZEu"\n", mapsize);
|
winpgnt.c: handle arbitrarily large file mappings.
I heard recently that at least one third-party client of Pageant
exists, and that it's used to generate signatures to use with TLS
client certificates. Apparently the signature scheme is compatible,
but TLS tends to need signatures over more data than will fit in
AGENT_MAX_MSGLEN.
Before the BinarySink refactor in commit b6cbad89f, this was OK
because the Windows Pageant IPC didn't check the size of the _input_
message against AGENT_MAX_MSGLEN, only the output one. But then we
started checking both, so that third-party TLS client started failing.
Now we use VirtualQuery to find out the actual size of the file
mapping we've been passed, and our only requirement is that the input
and output messages should both fit in _that_. So TLS should work
again, and also, other clients should be able to retrieve longer lists
of public keys if they pass a larger file mapping.
One side effect of this change is that Pageant's reply message is now
written directly into the shared-memory region. Previously, it was
written into a separate buffer and then memcpy()ed over after
pageant_handle_msg returned, but now the buffer is variable-size, it
seems to me to make more sense to avoid that extra not-entirely
controlled malloc. So I've done one very small reordering of
statements in the cross-platform pageant_handle_msg(), which fixes the
only case I could find where that function started writing its output
before it had finished using the contents of the input buffer.
2018-07-08 15:46:32 +00:00
|
|
|
#endif
|
|
|
|
if (mapsize < 5) {
|
|
|
|
err = dupstr("mapping smaller than smallest possible request");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
wmct.length = (char *)mapaddr;
|
|
|
|
msglen = GET_32BIT_MSB_FIRST(wmct.length);
|
2018-07-08 14:29:41 +00:00
|
|
|
|
|
|
|
#ifdef DEBUG_IPC
|
Start using C99 variadic macros.
In the past, I've had a lot of macros which you call with double
parentheses, along the lines of debug(("format string", params)), so
that the inner parens protect the commas and permit the macro to treat
the whole printf-style argument list as one macro argument.
That's all very well, but it's a bit inconvenient (it doesn't leave
you any way to implement such a macro by prepending another argument
to the list), and now this code base's rules allow C99isms, I can
switch all those macros to using a single pair of parens, using the
C99 ability to say '...' in the parameter list of the #define and get
at the corresponding suffix of the arguments as __VA_ARGS__.
So I'm doing it. I've made the following printf-style macros variadic:
bpp_logevent, ppl_logevent, ppl_printf and debug.
While I'm here, I've also fixed up a collection of conditioned-out
calls to debug() in the Windows front end which were clearly expecting
a macro with a different calling syntax, because they had an integer
parameter first. If I ever have a need to condition those back in,
they should actually work now.
2018-12-08 20:32:31 +00:00
|
|
|
debug("msg length=%08x, msg type=%02x\n",
|
|
|
|
msglen, (unsigned)((unsigned char *) mapaddr)[4]);
|
2018-07-08 14:29:41 +00:00
|
|
|
#endif
|
|
|
|
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
wmct.body = wmct.length + 4;
|
|
|
|
wmct.bodysize = mapsize - 4;
|
|
|
|
|
|
|
|
if (msglen > wmct.bodysize) {
|
|
|
|
/* Incoming length field is too large. Emit a failure response
|
|
|
|
* without even trying to handle the request.
|
|
|
|
*
|
|
|
|
* (We know this must fit, because we checked mapsize >= 5
|
|
|
|
* above.) */
|
|
|
|
PUT_32BIT_MSB_FIRST(wmct.length, 1);
|
|
|
|
*wmct.body = SSH_AGENT_FAILURE;
|
2018-07-08 14:29:41 +00:00
|
|
|
} else {
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
wmct.bodylen = msglen;
|
|
|
|
SetEvent(wmct.ev_msg_ready);
|
|
|
|
WaitForSingleObject(wmct.ev_reply_ready, INFINITE);
|
2018-07-08 14:29:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
/* expectedsid has the lifetime of the program, so we don't free it */
|
|
|
|
sfree(expectedsid_bc);
|
|
|
|
if (psd)
|
|
|
|
LocalFree(psd);
|
|
|
|
if (mapaddr)
|
|
|
|
UnmapViewOfFile(mapaddr);
|
|
|
|
if (maphandle != NULL && maphandle != INVALID_HANDLE_VALUE)
|
|
|
|
CloseHandle(maphandle);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
static LRESULT CALLBACK TrayWndProc(HWND hwnd, UINT message,
|
|
|
|
WPARAM wParam, LPARAM lParam)
|
2001-05-06 14:35:20 +00:00
|
|
|
{
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
static bool menuinprogress;
|
2001-09-25 20:05:06 +00:00
|
|
|
static UINT msgTaskbarCreated = 0;
|
2000-09-14 15:02:50 +00:00
|
|
|
|
|
|
|
switch (message) {
|
2001-09-25 20:05:06 +00:00
|
|
|
case WM_CREATE:
|
|
|
|
msgTaskbarCreated = RegisterWindowMessage(_T("TaskbarCreated"));
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
if (message==msgTaskbarCreated) {
|
2001-09-25 20:07:12 +00:00
|
|
|
/*
|
2019-09-08 19:29:00 +00:00
|
|
|
* Explorer has been restarted, so the tray icon will
|
|
|
|
* have been lost.
|
|
|
|
*/
|
|
|
|
AddTrayIcon(hwnd);
|
2001-09-25 20:05:06 +00:00
|
|
|
}
|
|
|
|
break;
|
2019-09-08 19:29:00 +00:00
|
|
|
|
2000-09-14 15:02:50 +00:00
|
|
|
case WM_SYSTRAY:
|
2019-09-08 19:29:00 +00:00
|
|
|
if (lParam == WM_RBUTTONUP) {
|
|
|
|
POINT cursorpos;
|
|
|
|
GetCursorPos(&cursorpos);
|
|
|
|
PostMessage(hwnd, WM_SYSTRAY2, cursorpos.x, cursorpos.y);
|
|
|
|
} else if (lParam == WM_LBUTTONDBLCLK) {
|
|
|
|
/* Run the default menu item. */
|
|
|
|
UINT menuitem = GetMenuDefaultItem(systray_menu, false, 0);
|
|
|
|
if (menuitem != -1)
|
|
|
|
PostMessage(hwnd, WM_COMMAND, menuitem, 0);
|
|
|
|
}
|
|
|
|
break;
|
2000-09-14 15:02:50 +00:00
|
|
|
case WM_SYSTRAY2:
|
2019-09-08 19:29:00 +00:00
|
|
|
if (!menuinprogress) {
|
|
|
|
menuinprogress = true;
|
|
|
|
update_sessions();
|
|
|
|
SetForegroundWindow(hwnd);
|
|
|
|
TrackPopupMenu(systray_menu,
|
|
|
|
TPM_RIGHTALIGN | TPM_BOTTOMALIGN |
|
|
|
|
TPM_RIGHTBUTTON,
|
|
|
|
wParam, lParam, 0, hwnd, NULL);
|
|
|
|
menuinprogress = false;
|
|
|
|
}
|
|
|
|
break;
|
2000-09-14 15:02:50 +00:00
|
|
|
case WM_COMMAND:
|
|
|
|
case WM_SYSCOMMAND:
|
2019-09-08 19:29:00 +00:00
|
|
|
switch (wParam & ~0xF) { /* low 4 bits reserved to Windows */
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
case IDM_PUTTY: {
|
|
|
|
TCHAR cmdline[10];
|
|
|
|
cmdline[0] = '\0';
|
|
|
|
if (restrict_putty_acl)
|
|
|
|
strcat(cmdline, "&R");
|
|
|
|
|
|
|
|
if((INT_PTR)ShellExecute(hwnd, NULL, putty_path, cmdline,
|
|
|
|
_T(""), SW_SHOW) <= 32) {
|
|
|
|
MessageBox(NULL, "Unable to execute PuTTY!",
|
|
|
|
"Error", MB_OK | MB_ICONERROR);
|
2017-09-20 17:04:37 +00:00
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
break;
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
case IDM_CLOSE:
|
2020-03-21 15:59:51 +00:00
|
|
|
if (modal_passphrase_hwnd)
|
|
|
|
SendMessage(modal_passphrase_hwnd, WM_CLOSE, 0, 0);
|
2019-09-08 19:29:00 +00:00
|
|
|
SendMessage(hwnd, WM_CLOSE, 0, 0);
|
|
|
|
break;
|
|
|
|
case IDM_VIEWKEYS:
|
|
|
|
if (!keylist) {
|
|
|
|
keylist = CreateDialog(hinst, MAKEINTRESOURCE(211),
|
|
|
|
NULL, KeyListProc);
|
|
|
|
ShowWindow(keylist, SW_SHOWNORMAL);
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Sometimes the window comes up minimised / hidden for
|
|
|
|
* no obvious reason. Prevent this. This also brings it
|
|
|
|
* to the front if it's already present (the user
|
|
|
|
* selected View Keys because they wanted to _see_ the
|
|
|
|
* thing).
|
|
|
|
*/
|
|
|
|
SetForegroundWindow(keylist);
|
|
|
|
SetWindowPos(keylist, HWND_TOP, 0, 0, 0, 0,
|
|
|
|
SWP_NOMOVE | SWP_NOSIZE | SWP_SHOWWINDOW);
|
|
|
|
break;
|
|
|
|
case IDM_ADDKEY:
|
2020-03-21 15:59:51 +00:00
|
|
|
if (modal_passphrase_hwnd) {
|
2019-09-08 19:29:00 +00:00
|
|
|
MessageBeep(MB_ICONERROR);
|
2020-03-21 15:59:51 +00:00
|
|
|
SetForegroundWindow(modal_passphrase_hwnd);
|
2019-09-08 19:29:00 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
prompt_add_keyfile();
|
|
|
|
break;
|
|
|
|
case IDM_ABOUT:
|
|
|
|
if (!aboutbox) {
|
|
|
|
aboutbox = CreateDialog(hinst, MAKEINTRESOURCE(213),
|
|
|
|
NULL, AboutProc);
|
|
|
|
ShowWindow(aboutbox, SW_SHOWNORMAL);
|
|
|
|
/*
|
|
|
|
* Sometimes the window comes up minimised / hidden
|
|
|
|
* for no obvious reason. Prevent this.
|
|
|
|
*/
|
|
|
|
SetForegroundWindow(aboutbox);
|
|
|
|
SetWindowPos(aboutbox, HWND_TOP, 0, 0, 0, 0,
|
|
|
|
SWP_NOMOVE | SWP_NOSIZE | SWP_SHOWWINDOW);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case IDM_HELP:
|
|
|
|
launch_help(hwnd, WINHELP_CTX_pageant_general);
|
|
|
|
break;
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
default: {
|
|
|
|
if(wParam >= IDM_SESSIONS_BASE && wParam <= IDM_SESSIONS_MAX) {
|
|
|
|
MENUITEMINFO mii;
|
|
|
|
TCHAR buf[MAX_PATH + 1];
|
|
|
|
TCHAR param[MAX_PATH + 1];
|
|
|
|
memset(&mii, 0, sizeof(mii));
|
|
|
|
mii.cbSize = sizeof(mii);
|
|
|
|
mii.fMask = MIIM_TYPE;
|
|
|
|
mii.cch = MAX_PATH;
|
|
|
|
mii.dwTypeData = buf;
|
|
|
|
GetMenuItemInfo(session_menu, wParam, false, &mii);
|
|
|
|
param[0] = '\0';
|
|
|
|
if (restrict_putty_acl)
|
|
|
|
strcat(param, "&R");
|
|
|
|
strcat(param, "@");
|
|
|
|
strcat(param, mii.dwTypeData);
|
|
|
|
if((INT_PTR)ShellExecute(hwnd, NULL, putty_path, param,
|
|
|
|
_T(""), SW_SHOW) <= 32) {
|
|
|
|
MessageBox(NULL, "Unable to execute PuTTY!", "Error",
|
|
|
|
MB_OK | MB_ICONERROR);
|
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
|
|
|
break;
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
}
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
|
|
|
break;
|
2000-09-14 15:02:50 +00:00
|
|
|
case WM_DESTROY:
|
2019-09-08 19:29:00 +00:00
|
|
|
quit_help(hwnd);
|
|
|
|
PostQuitMessage(0);
|
|
|
|
return 0;
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return DefWindowProc(hwnd, message, wParam, lParam);
|
|
|
|
}
|
|
|
|
|
|
|
|
static LRESULT CALLBACK wm_copydata_WndProc(HWND hwnd, UINT message,
|
|
|
|
WPARAM wParam, LPARAM lParam)
|
|
|
|
{
|
|
|
|
switch (message) {
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
case WM_COPYDATA: {
|
|
|
|
COPYDATASTRUCT *cds;
|
|
|
|
char *mapname, *err;
|
|
|
|
|
|
|
|
cds = (COPYDATASTRUCT *) lParam;
|
|
|
|
if (cds->dwData != AGENT_COPYDATA_ID)
|
|
|
|
return 0; /* not our message, mate */
|
|
|
|
mapname = (char *) cds->lpData;
|
|
|
|
if (mapname[cds->cbData - 1] != '\0')
|
|
|
|
return 0; /* failure to be ASCIZ! */
|
|
|
|
err = answer_filemapping_message(mapname);
|
|
|
|
if (err) {
|
2000-09-19 16:29:28 +00:00
|
|
|
#ifdef DEBUG_IPC
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
debug("IPC failed: %s\n", err);
|
2000-09-19 16:29:28 +00:00
|
|
|
#endif
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
sfree(err);
|
|
|
|
return 0;
|
2019-09-08 19:29:00 +00:00
|
|
|
}
|
Formatting change to braces around one case of a switch.
Sometimes, within a switch statement, you want to declare local
variables specific to the handler for one particular case. Until now
I've mostly been writing this in the form
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED:
{
declare variables;
do stuff;
}
break;
}
which is ugly because the two pieces of essentially similar code
appear at different indent levels, and also inconvenient because you
have less horizontal space available to write the complicated case
handler in - particuarly undesirable because _complicated_ case
handlers are the ones most likely to need all the space they can get!
After encountering a rather nicer idiom in the LLVM source code, and
after a bit of hackery this morning figuring out how to persuade
Emacs's auto-indent to do what I wanted with it, I've decided to move
to an idiom in which the open brace comes right after the case
statement, and the code within it is indented the same as it would
have been without the brace. Then the whole case handler (including
the break) lives inside those braces, and you get something that looks
more like this:
switch (discriminant) {
case SIMPLE:
do stuff;
break;
case COMPLICATED: {
declare variables;
do stuff;
break;
}
}
This commit is a big-bang change that reformats all the complicated
case handlers I could find into the new layout. This is particularly
nice in the Pageant main function, in which almost _every_ case
handler had a bundle of variables and was long and complicated. (In
fact that's what motivated me to get round to this.) Some of the
innermost parts of the terminal escape-sequence handling are also
breathing a bit easier now the horizontal pressure on them is
relieved.
(Also, in a few cases, I was able to remove the extra braces
completely, because the only variable local to the case handler was a
loop variable which our new C99 policy allows me to move into the
initialiser clause of its for statement.)
Viewed with whitespace ignored, this is not too disruptive a change.
Downstream patches that conflict with it may need to be reapplied
using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
|
|
|
return 1;
|
|
|
|
}
|
2000-09-14 15:02:50 +00:00
|
|
|
}
|
|
|
|
|
2001-05-06 14:35:20 +00:00
|
|
|
return DefWindowProc(hwnd, message, wParam, lParam);
|
2000-09-14 15:02:50 +00:00
|
|
|
}
|
|
|
|
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
static DWORD WINAPI wm_copydata_threadfunc(void *param)
|
|
|
|
{
|
|
|
|
HINSTANCE inst = *(HINSTANCE *)param;
|
|
|
|
|
|
|
|
HWND ipchwnd = CreateWindow(IPCCLASSNAME, IPCWINTITLE,
|
|
|
|
WS_OVERLAPPEDWINDOW | WS_VSCROLL,
|
|
|
|
CW_USEDEFAULT, CW_USEDEFAULT,
|
|
|
|
100, 100, NULL, NULL, inst, NULL);
|
|
|
|
ShowWindow(ipchwnd, SW_HIDE);
|
|
|
|
|
|
|
|
MSG msg;
|
|
|
|
while (GetMessage(&msg, NULL, 0, 0) == 1) {
|
|
|
|
TranslateMessage(&msg);
|
|
|
|
DispatchMessage(&msg);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2001-04-16 11:16:58 +00:00
|
|
|
/*
|
|
|
|
* Fork and Exec the command in cmdline. [DBW]
|
|
|
|
*/
|
2015-05-15 10:15:42 +00:00
|
|
|
void spawn_cmd(const char *cmdline, const char *args, int show)
|
2001-05-06 14:35:20 +00:00
|
|
|
{
|
2001-04-16 11:16:58 +00:00
|
|
|
if (ShellExecute(NULL, _T("open"), cmdline,
|
2019-09-08 19:29:00 +00:00
|
|
|
args, NULL, show) <= (HINSTANCE) 32) {
|
|
|
|
char *msg;
|
|
|
|
msg = dupprintf("Failed to run \"%s\": %s", cmdline,
|
|
|
|
win_strerror(GetLastError()));
|
|
|
|
MessageBox(NULL, msg, APPNAME, MB_OK | MB_ICONEXCLAMATION);
|
|
|
|
sfree(msg);
|
2001-04-16 11:16:58 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-01-01 15:55:06 +00:00
|
|
|
void logevent(LogContext *logctx, const char *event)
|
|
|
|
{
|
|
|
|
unreachable("Pageant can't create a LogContext, so this can't be called");
|
|
|
|
}
|
|
|
|
|
|
|
|
void noise_ultralight(NoiseSourceId id, unsigned long data)
|
|
|
|
{
|
|
|
|
/* Pageant doesn't use random numbers, so we ignore this */
|
|
|
|
}
|
|
|
|
|
2006-12-17 11:16:07 +00:00
|
|
|
void cleanup_exit(int code)
|
|
|
|
{
|
|
|
|
shutdown_help();
|
|
|
|
exit(code);
|
|
|
|
}
|
2002-03-06 20:13:22 +00:00
|
|
|
|
2020-01-20 21:22:33 +00:00
|
|
|
static bool winpgnt_listener_ask_passphrase(
|
|
|
|
PageantListenerClient *plc, PageantClientDialogId *dlgid, const char *msg)
|
|
|
|
{
|
2020-03-21 15:59:51 +00:00
|
|
|
return ask_passphrase_common(dlgid, msg);
|
2020-01-20 21:22:33 +00:00
|
|
|
}
|
|
|
|
|
Pageant: new asynchronous internal APIs.
This is a pure refactoring: no functional change expected.
This commit introduces two new small vtable-style APIs. One is
PageantClient, which identifies a particular client of the Pageant
'core' (meaning the code that handles each individual request). This
changes pageant_handle_msg into an asynchronous operation: you pass in
an agent request message and an identifier, and at some later point,
the got_response method in your PageantClient will be called with the
answer (and the same identifier, to allow you to match requests to
responses). The trait vtable also contains a logging system.
The main importance of PageantClient, and the reason why it has to
exist instead of just passing pageant_handle_msg a bare callback
function pointer and context parameter, is that it provides robustness
if a client stops existing while a request is still pending. You call
pageant_unregister_client, and any unfinished requests associated with
that client in the Pageant core will be cleaned up, so that you're
guaranteed that after the unregister operation, no stray callbacks
will happen with a stale pointer to that client.
The WM_COPYDATA interface of Windows Pageant is a direct client of
this API. The other client is PageantListener, the system that lives
in pageant.c and handles stream-based agent connections for both Unix
Pageant and the new Windows named-pipe IPC. More specifically, each
individual connection to the listening socket is a separate
PageantClient, which means that if a socket is closed abruptly or
suffers an OS error, that client can be unregistered and any pending
requests cancelled without disrupting other connections.
Users of PageantListener have a second client vtable they can use,
called PageantListenerClient. That contains _only_ logging facilities,
and at the moment, only Unix Pageant bothers to use it (and even that
only in debugging mode).
Finally, internally to the Pageant core, there's a new trait called
PageantAsyncOp which describes an agent request in the process of
being handled. But at the moment, it has only one trivial
implementation, which is handed the full response message already
constructed, and on the next toplevel callback, passes it back to the
PageantClient.
2020-01-25 17:24:28 +00:00
|
|
|
struct winpgnt_client {
|
|
|
|
PageantListenerClient plc;
|
|
|
|
};
|
2020-01-29 06:22:01 +00:00
|
|
|
static const PageantListenerClientVtable winpgnt_vtable = {
|
Change vtable defs to use C99 designated initialisers.
This is a sweeping change applied across the whole code base by a spot
of Emacs Lisp. Now, everywhere I declare a vtable filled with function
pointers (and the occasional const data member), all the members of
the vtable structure are initialised by name using the '.fieldname =
value' syntax introduced in C99.
We were already using this syntax for a handful of things in the new
key-generation progress report system, so it's not new to the code
base as a whole.
The advantage is that now, when a vtable only declares a subset of the
available fields, I can initialise the rest to NULL or zero just by
leaving them out. This is most dramatic in a couple of the outlying
vtables in things like psocks (which has a ConnectionLayerVtable
containing only one non-NULL method), but less dramatically, it means
that the new 'flags' field in BackendVtable can be completely left out
of every backend definition except for the SUPDUP one which defines it
to a nonzero value. Similarly, the test_for_upstream method only used
by SSH doesn't have to be mentioned in the rest of the backends;
network Plugs for listening sockets don't have to explicitly null out
'receive' and 'sent', and vice versa for 'accepting', and so on.
While I'm at it, I've normalised the declarations so they don't use
the unnecessarily verbose 'struct' keyword. Also a handful of them
weren't const; now they are.
2020-03-10 21:06:29 +00:00
|
|
|
.log = NULL, /* no logging */
|
|
|
|
.ask_passphrase = winpgnt_listener_ask_passphrase,
|
Pageant: new asynchronous internal APIs.
This is a pure refactoring: no functional change expected.
This commit introduces two new small vtable-style APIs. One is
PageantClient, which identifies a particular client of the Pageant
'core' (meaning the code that handles each individual request). This
changes pageant_handle_msg into an asynchronous operation: you pass in
an agent request message and an identifier, and at some later point,
the got_response method in your PageantClient will be called with the
answer (and the same identifier, to allow you to match requests to
responses). The trait vtable also contains a logging system.
The main importance of PageantClient, and the reason why it has to
exist instead of just passing pageant_handle_msg a bare callback
function pointer and context parameter, is that it provides robustness
if a client stops existing while a request is still pending. You call
pageant_unregister_client, and any unfinished requests associated with
that client in the Pageant core will be cleaned up, so that you're
guaranteed that after the unregister operation, no stray callbacks
will happen with a stale pointer to that client.
The WM_COPYDATA interface of Windows Pageant is a direct client of
this API. The other client is PageantListener, the system that lives
in pageant.c and handles stream-based agent connections for both Unix
Pageant and the new Windows named-pipe IPC. More specifically, each
individual connection to the listening socket is a separate
PageantClient, which means that if a socket is closed abruptly or
suffers an OS error, that client can be unregistered and any pending
requests cancelled without disrupting other connections.
Users of PageantListener have a second client vtable they can use,
called PageantListenerClient. That contains _only_ logging facilities,
and at the moment, only Unix Pageant bothers to use it (and even that
only in debugging mode).
Finally, internally to the Pageant core, there's a new trait called
PageantAsyncOp which describes an agent request in the process of
being handled. But at the moment, it has only one trivial
implementation, which is handed the full response message already
constructed, and on the next toplevel callback, passes it back to the
PageantClient.
2020-01-25 17:24:28 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static struct winpgnt_client wpc[1];
|
|
|
|
|
Remove remaining uses of the GLOBAL macro.
We now have no remaining things in header files that switch from being
a declaration to a definition depending on an awkward #define at the
point of including that header. There are still a few mutable
variables with external linkage, but at least now each one is defined
in a specific source file file appropriate to its purpose and context.
The remaining globals as of this commit were:
- 'logctx' and 'term', which never needed to be globals in the first
place, because they were never actually shared between source
files. Now 'term' is just a static in window.c, and 'logctx' is a
static in each of that and winplink.c.
- 'hinst', which still has external linkage, but is now defined
separately in each source file that sets it up (i.e. those with a
WinMain)
- osMajorVersion, osMinorVersion and osPlatformId, whose definitions
now live in winmisc.c alongside the code which sets them up.
(Actually they were defined there all along, it turns out, but
every toolchain I've built with has commoned them together with the
version defined by the GLOBAL in the header.)
- 'hwnd', which nothing was actually _using_ any more after previous
commits, so all this commit had to do was delete it.
2020-02-02 10:00:43 +00:00
|
|
|
HINSTANCE hinst;
|
|
|
|
|
2001-05-06 14:35:20 +00:00
|
|
|
int WINAPI WinMain(HINSTANCE inst, HINSTANCE prev, LPSTR cmdline, int show)
|
|
|
|
{
|
2000-09-14 15:02:50 +00:00
|
|
|
MSG msg;
|
2015-05-15 10:15:42 +00:00
|
|
|
const char *command = NULL;
|
Convert a lot of 'int' variables to 'bool'.
My normal habit these days, in new code, is to treat int and bool as
_almost_ completely separate types. I'm still willing to use C's
implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine,
no need to spell it out as blob.len != 0), but generally, if a
variable is going to be conceptually a boolean, I like to declare it
bool and assign to it using 'true' or 'false' rather than 0 or 1.
PuTTY is an exception, because it predates the C99 bool, and I've
stuck to its existing coding style even when adding new code to it.
But it's been annoying me more and more, so now that I've decided C99
bool is an acceptable thing to require from our toolchain in the first
place, here's a quite thorough trawl through the source doing
'boolification'. Many variables and function parameters are now typed
as bool rather than int; many assignments of 0 or 1 to those variables
are now spelled 'true' or 'false'.
I managed this thorough conversion with the help of a custom clang
plugin that I wrote to trawl the AST and apply heuristics to point out
where things might want changing. So I've even managed to do a decent
job on parts of the code I haven't looked at in years!
To make the plugin's work easier, I pushed platform front ends
generally in the direction of using standard 'bool' in preference to
platform-specific boolean types like Windows BOOL or GTK's gboolean;
I've left the platform booleans in places they _have_ to be for the
platform APIs to work right, but variables only used by my own code
have been converted wherever I found them.
In a few places there are int values that look very like booleans in
_most_ of the places they're used, but have a rarely-used third value,
or a distinction between different nonzero values that most users
don't care about. In these cases, I've _removed_ uses of 'true' and
'false' for the return values, to emphasise that there's something
more subtle going on than a simple boolean answer:
- the 'multisel' field in dialog.h's list box structure, for which
the GTK front end in particular recognises a difference between 1
and 2 but nearly everything else treats as boolean
- the 'urgent' parameter to plug_receive, where 1 vs 2 tells you
something about the specific location of the urgent pointer, but
most clients only care about 0 vs 'something nonzero'
- the return value of wc_match, where -1 indicates a syntax error in
the wildcard.
- the return values from SSH-1 RSA-key loading functions, which use
-1 for 'wrong passphrase' and 0 for all other failures (so any
caller which already knows it's not loading an _encrypted private_
key can treat them as boolean)
- term->esc_query, and the 'query' parameter in toggle_mode in
terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h,
but can also hold -1 for some other intervening character that we
don't support.
In a few places there's an integer that I haven't turned into a bool
even though it really _can_ only take values 0 or 1 (and, as above,
tried to make the call sites consistent in not calling those values
true and false), on the grounds that I thought it would make it more
confusing to imply that the 0 value was in some sense 'negative' or
bad and the 1 positive or good:
- the return value of plug_accepting uses the POSIXish convention of
0=success and nonzero=error; I think if I made it bool then I'd
also want to reverse its sense, and that's a job for a separate
piece of work.
- the 'screen' parameter to lineptr() in terminal.c, where 0 and 1
represent the default and alternate screens. There's no obvious
reason why one of those should be considered 'true' or 'positive'
or 'success' - they're just indices - so I've left it as int.
ssh_scp_recv had particularly confusing semantics for its previous int
return value: its call sites used '<= 0' to check for error, but it
never actually returned a negative number, just 0 or 1. Now the
function and its call sites agree that it's a bool.
In a couple of places I've renamed variables called 'ret', because I
don't like that name any more - it's unclear whether it means the
return value (in preparation) for the _containing_ function or the
return value received from a subroutine call, and occasionally I've
accidentally used the same variable for both and introduced a bug. So
where one of those got in my way, I've renamed it to 'toret' or 'retd'
(the latter short for 'returned') in line with my usual modern
practice, but I haven't done a thorough job of finding all of them.
Finally, one amusing side effect of doing this is that I've had to
separate quite a few chained assignments. It used to be perfectly fine
to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a
the 'true' defined by stdbool.h, that idiom provokes a warning from
gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
|
|
|
bool added_keys = false;
|
2002-08-06 17:57:37 +00:00
|
|
|
int argc, i;
|
|
|
|
char **argv, **argstart;
|
2000-09-26 09:22:40 +00:00
|
|
|
|
2016-07-18 19:02:32 +00:00
|
|
|
dll_hijacking_protection();
|
|
|
|
|
2005-03-01 01:16:57 +00:00
|
|
|
hinst = inst;
|
|
|
|
|
2000-09-26 09:22:40 +00:00
|
|
|
/*
|
|
|
|
* Determine whether we're an NT system (should have security
|
|
|
|
* APIs) or a non-NT system (don't do security).
|
|
|
|
*/
|
2018-06-03 14:05:44 +00:00
|
|
|
init_winver();
|
|
|
|
has_security = (osPlatformId == VER_PLATFORM_WIN32_NT);
|
2000-09-26 09:22:40 +00:00
|
|
|
|
|
|
|
if (has_security) {
|
2000-10-09 09:10:09 +00:00
|
|
|
#ifndef NO_SECURITY
|
2019-09-08 19:29:00 +00:00
|
|
|
/*
|
|
|
|
* Attempt to get the security API we need.
|
|
|
|
*/
|
2013-11-17 14:05:29 +00:00
|
|
|
if (!got_advapi()) {
|
2019-09-08 19:29:00 +00:00
|
|
|
MessageBox(NULL,
|
|
|
|
"Unable to access security APIs. Pageant will\n"
|
|
|
|
"not run, in case it causes a security breach.",
|
|
|
|
"Pageant Fatal Error", MB_ICONERROR | MB_OK);
|
|
|
|
return 1;
|
|
|
|
}
|
2000-10-09 09:10:09 +00:00
|
|
|
#else
|
2019-09-08 19:29:00 +00:00
|
|
|
MessageBox(NULL,
|
|
|
|
"This program has been compiled for Win9X and will\n"
|
|
|
|
"not run on NT, in case it causes a security breach.",
|
|
|
|
"Pageant Fatal Error", MB_ICONERROR | MB_OK);
|
|
|
|
return 1;
|
2000-10-09 09:10:09 +00:00
|
|
|
#endif
|
2013-07-24 19:18:06 +00:00
|
|
|
}
|
2000-09-14 15:02:50 +00:00
|
|
|
|
2001-12-11 18:48:29 +00:00
|
|
|
/*
|
|
|
|
* See if we can find our Help file.
|
|
|
|
*/
|
2006-12-17 11:16:07 +00:00
|
|
|
init_help();
|
2001-12-11 18:48:29 +00:00
|
|
|
|
2002-03-27 20:30:57 +00:00
|
|
|
/*
|
|
|
|
* Look for the PuTTY binary (we will enable the saved session
|
|
|
|
* submenu if we find it).
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
char b[2048], *p, *q, *r;
|
|
|
|
FILE *fp;
|
2010-12-21 10:11:32 +00:00
|
|
|
GetModuleFileName(NULL, b, sizeof(b) - 16);
|
2002-03-27 20:30:57 +00:00
|
|
|
r = b;
|
|
|
|
p = strrchr(b, '\\');
|
|
|
|
if (p && p >= r) r = p+1;
|
|
|
|
q = strrchr(b, ':');
|
|
|
|
if (q && q >= r) r = q+1;
|
|
|
|
strcpy(r, "putty.exe");
|
|
|
|
if ( (fp = fopen(b, "r")) != NULL) {
|
|
|
|
putty_path = dupstr(b);
|
|
|
|
fclose(fp);
|
|
|
|
} else
|
|
|
|
putty_path = NULL;
|
|
|
|
}
|
|
|
|
|
2001-04-16 11:16:58 +00:00
|
|
|
/*
|
|
|
|
* Find out if Pageant is already running.
|
|
|
|
*/
|
2005-03-19 02:26:58 +00:00
|
|
|
already_running = agent_exists();
|
2004-11-20 18:29:58 +00:00
|
|
|
|
2005-03-19 02:26:58 +00:00
|
|
|
/*
|
2015-05-05 19:16:19 +00:00
|
|
|
* Initialise the cross-platform Pageant code.
|
2005-03-19 02:26:58 +00:00
|
|
|
*/
|
|
|
|
if (!already_running) {
|
2015-05-05 19:16:19 +00:00
|
|
|
pageant_init();
|
2001-04-16 11:16:58 +00:00
|
|
|
}
|
2000-09-15 10:48:42 +00:00
|
|
|
|
|
|
|
/*
|
2001-03-03 15:31:35 +00:00
|
|
|
* Process the command line and add keys as listed on it.
|
2000-09-14 15:02:50 +00:00
|
|
|
*/
|
2002-08-06 17:57:37 +00:00
|
|
|
split_into_argv(cmdline, &argc, &argv, &argstart);
|
|
|
|
for (i = 0; i < argc; i++) {
|
2019-09-08 19:29:00 +00:00
|
|
|
if (!strcmp(argv[i], "-pgpfp")) {
|
2020-02-02 10:00:42 +00:00
|
|
|
pgp_fingerprints_msgbox(NULL);
|
2019-09-08 19:29:00 +00:00
|
|
|
return 1;
|
2017-01-28 21:56:28 +00:00
|
|
|
} else if (!strcmp(argv[i], "-restrict-acl") ||
|
|
|
|
!strcmp(argv[i], "-restrict_acl") ||
|
|
|
|
!strcmp(argv[i], "-restrictacl")) {
|
|
|
|
restrict_process_acl();
|
2017-09-20 17:04:37 +00:00
|
|
|
} else if (!strcmp(argv[i], "-restrict-putty-acl") ||
|
|
|
|
!strcmp(argv[i], "-restrict_putty_acl")) {
|
2018-10-29 19:50:29 +00:00
|
|
|
restrict_putty_acl = true;
|
2019-09-08 19:29:00 +00:00
|
|
|
} else if (!strcmp(argv[i], "-c")) {
|
|
|
|
/*
|
|
|
|
* If we see `-c', then the rest of the
|
|
|
|
* command line should be treated as a
|
|
|
|
* command to be spawned.
|
|
|
|
*/
|
|
|
|
if (i < argc-1)
|
|
|
|
command = argstart[i+1];
|
|
|
|
else
|
|
|
|
command = "";
|
|
|
|
break;
|
|
|
|
} else {
|
2013-07-22 07:11:54 +00:00
|
|
|
Filename *fn = filename_from_str(argv[i]);
|
2019-09-08 19:29:00 +00:00
|
|
|
win_add_keyfile(fn);
|
2013-07-22 07:11:54 +00:00
|
|
|
filename_free(fn);
|
2019-09-08 19:29:00 +00:00
|
|
|
added_keys = true;
|
|
|
|
}
|
2000-09-14 15:02:50 +00:00
|
|
|
}
|
|
|
|
|
2001-12-10 17:40:14 +00:00
|
|
|
/*
|
|
|
|
* Forget any passphrase that we retained while going over
|
|
|
|
* command line keyfiles.
|
|
|
|
*/
|
2015-05-11 14:06:25 +00:00
|
|
|
pageant_forget_passphrases();
|
2001-12-10 17:40:14 +00:00
|
|
|
|
2001-12-10 17:50:03 +00:00
|
|
|
if (command) {
|
2019-09-08 19:29:00 +00:00
|
|
|
char *args;
|
|
|
|
if (command[0] == '"')
|
|
|
|
args = strchr(++command, '"');
|
|
|
|
else
|
|
|
|
args = strchr(command, ' ');
|
|
|
|
if (args) {
|
|
|
|
*args++ = 0;
|
|
|
|
while(*args && isspace(*args)) args++;
|
|
|
|
}
|
|
|
|
spawn_cmd(command, args, show);
|
2001-12-10 17:50:03 +00:00
|
|
|
}
|
2001-04-16 11:16:58 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If Pageant was already running, we leave now. If we haven't
|
|
|
|
* even taken any auxiliary action (spawned a command or added
|
|
|
|
* keys), complain.
|
|
|
|
*/
|
|
|
|
if (already_running) {
|
2019-09-08 19:29:00 +00:00
|
|
|
if (!command && !added_keys) {
|
|
|
|
MessageBox(NULL, "Pageant is already running", "Pageant Error",
|
|
|
|
MB_ICONERROR | MB_OK);
|
|
|
|
}
|
|
|
|
return 0;
|
2001-04-16 11:16:58 +00:00
|
|
|
}
|
|
|
|
|
2020-01-01 15:55:06 +00:00
|
|
|
#if !defined NO_SECURITY
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set up a named-pipe listener.
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
Plug *pl_plug;
|
Pageant: new asynchronous internal APIs.
This is a pure refactoring: no functional change expected.
This commit introduces two new small vtable-style APIs. One is
PageantClient, which identifies a particular client of the Pageant
'core' (meaning the code that handles each individual request). This
changes pageant_handle_msg into an asynchronous operation: you pass in
an agent request message and an identifier, and at some later point,
the got_response method in your PageantClient will be called with the
answer (and the same identifier, to allow you to match requests to
responses). The trait vtable also contains a logging system.
The main importance of PageantClient, and the reason why it has to
exist instead of just passing pageant_handle_msg a bare callback
function pointer and context parameter, is that it provides robustness
if a client stops existing while a request is still pending. You call
pageant_unregister_client, and any unfinished requests associated with
that client in the Pageant core will be cleaned up, so that you're
guaranteed that after the unregister operation, no stray callbacks
will happen with a stale pointer to that client.
The WM_COPYDATA interface of Windows Pageant is a direct client of
this API. The other client is PageantListener, the system that lives
in pageant.c and handles stream-based agent connections for both Unix
Pageant and the new Windows named-pipe IPC. More specifically, each
individual connection to the listening socket is a separate
PageantClient, which means that if a socket is closed abruptly or
suffers an OS error, that client can be unregistered and any pending
requests cancelled without disrupting other connections.
Users of PageantListener have a second client vtable they can use,
called PageantListenerClient. That contains _only_ logging facilities,
and at the moment, only Unix Pageant bothers to use it (and even that
only in debugging mode).
Finally, internally to the Pageant core, there's a new trait called
PageantAsyncOp which describes an agent request in the process of
being handled. But at the moment, it has only one trivial
implementation, which is handed the full response message already
constructed, and on the next toplevel callback, passes it back to the
PageantClient.
2020-01-25 17:24:28 +00:00
|
|
|
wpc->plc.vt = &winpgnt_vtable;
|
|
|
|
wpc->plc.suppress_logging = true;
|
|
|
|
struct pageant_listen_state *pl =
|
|
|
|
pageant_listener_new(&pl_plug, &wpc->plc);
|
2020-01-01 15:55:06 +00:00
|
|
|
char *pipename = agent_named_pipe_name();
|
|
|
|
Socket *sock = new_named_pipe_listener(pipename, pl_plug);
|
|
|
|
if (sk_socket_error(sock)) {
|
|
|
|
char *err = dupprintf("Unable to open named pipe at %s "
|
2020-01-05 01:33:14 +00:00
|
|
|
"for SSH agent:\n%s", pipename,
|
2020-01-01 15:55:06 +00:00
|
|
|
sk_socket_error(sock));
|
|
|
|
MessageBox(NULL, err, "Pageant Error", MB_ICONERROR | MB_OK);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
pageant_listener_got_socket(pl, sock);
|
|
|
|
sfree(pipename);
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* !defined NO_SECURITY */
|
|
|
|
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
/*
|
|
|
|
* Set up window classes for two hidden windows: one that receives
|
|
|
|
* all the messages to do with our presence in the system tray,
|
|
|
|
* and one that receives the WM_COPYDATA message used by the
|
|
|
|
* old-style Pageant IPC system.
|
|
|
|
*/
|
|
|
|
|
2005-03-19 02:26:58 +00:00
|
|
|
if (!prev) {
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
WNDCLASS wndclass;
|
|
|
|
|
|
|
|
memset(&wndclass, 0, sizeof(wndclass));
|
|
|
|
wndclass.lpfnWndProc = TrayWndProc;
|
2019-09-08 19:29:00 +00:00
|
|
|
wndclass.hInstance = inst;
|
|
|
|
wndclass.hIcon = LoadIcon(inst, MAKEINTRESOURCE(IDI_MAINICON));
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
wndclass.lpszClassName = TRAYCLASSNAME;
|
|
|
|
|
|
|
|
RegisterClass(&wndclass);
|
|
|
|
|
|
|
|
memset(&wndclass, 0, sizeof(wndclass));
|
|
|
|
wndclass.lpfnWndProc = wm_copydata_WndProc;
|
|
|
|
wndclass.hInstance = inst;
|
|
|
|
wndclass.lpszClassName = IPCCLASSNAME;
|
2019-09-08 19:29:00 +00:00
|
|
|
|
|
|
|
RegisterClass(&wndclass);
|
2005-03-19 02:26:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
keylist = NULL;
|
|
|
|
|
2020-02-02 10:00:43 +00:00
|
|
|
traywindow = CreateWindow(TRAYCLASSNAME, TRAYWINTITLE,
|
|
|
|
WS_OVERLAPPEDWINDOW | WS_VSCROLL,
|
|
|
|
CW_USEDEFAULT, CW_USEDEFAULT,
|
|
|
|
100, 100, NULL, NULL, inst, NULL);
|
|
|
|
winselgui_set_hwnd(traywindow);
|
2005-03-19 02:26:58 +00:00
|
|
|
|
|
|
|
/* Set up a system tray icon */
|
2020-02-02 10:00:43 +00:00
|
|
|
AddTrayIcon(traywindow);
|
2005-03-19 02:26:58 +00:00
|
|
|
|
|
|
|
/* Accelerators used: nsvkxa */
|
|
|
|
systray_menu = CreatePopupMenu();
|
|
|
|
if (putty_path) {
|
2019-09-08 19:29:00 +00:00
|
|
|
session_menu = CreateMenu();
|
|
|
|
AppendMenu(systray_menu, MF_ENABLED, IDM_PUTTY, "&New Session");
|
|
|
|
AppendMenu(systray_menu, MF_POPUP | MF_ENABLED,
|
|
|
|
(UINT_PTR) session_menu, "&Saved Sessions");
|
|
|
|
AppendMenu(systray_menu, MF_SEPARATOR, 0, 0);
|
2005-03-19 02:26:58 +00:00
|
|
|
}
|
|
|
|
AppendMenu(systray_menu, MF_ENABLED, IDM_VIEWKEYS,
|
2019-09-08 19:29:00 +00:00
|
|
|
"&View Keys");
|
2005-03-19 02:26:58 +00:00
|
|
|
AppendMenu(systray_menu, MF_ENABLED, IDM_ADDKEY, "Add &Key");
|
|
|
|
AppendMenu(systray_menu, MF_SEPARATOR, 0, 0);
|
2006-12-17 11:16:07 +00:00
|
|
|
if (has_help())
|
2019-09-08 19:29:00 +00:00
|
|
|
AppendMenu(systray_menu, MF_ENABLED, IDM_HELP, "&Help");
|
2005-03-19 02:26:58 +00:00
|
|
|
AppendMenu(systray_menu, MF_ENABLED, IDM_ABOUT, "&About");
|
|
|
|
AppendMenu(systray_menu, MF_SEPARATOR, 0, 0);
|
|
|
|
AppendMenu(systray_menu, MF_ENABLED, IDM_CLOSE, "E&xit");
|
|
|
|
initial_menuitems_count = GetMenuItemCount(session_menu);
|
|
|
|
|
|
|
|
/* Set the default menu item. */
|
2018-10-29 19:50:29 +00:00
|
|
|
SetMenuDefaultItem(systray_menu, IDM_VIEWKEYS, false);
|
2005-03-19 02:26:58 +00:00
|
|
|
|
2020-02-02 10:00:43 +00:00
|
|
|
ShowWindow(traywindow, SW_HIDE);
|
2005-03-19 02:26:58 +00:00
|
|
|
|
Pageant: new asynchronous internal APIs.
This is a pure refactoring: no functional change expected.
This commit introduces two new small vtable-style APIs. One is
PageantClient, which identifies a particular client of the Pageant
'core' (meaning the code that handles each individual request). This
changes pageant_handle_msg into an asynchronous operation: you pass in
an agent request message and an identifier, and at some later point,
the got_response method in your PageantClient will be called with the
answer (and the same identifier, to allow you to match requests to
responses). The trait vtable also contains a logging system.
The main importance of PageantClient, and the reason why it has to
exist instead of just passing pageant_handle_msg a bare callback
function pointer and context parameter, is that it provides robustness
if a client stops existing while a request is still pending. You call
pageant_unregister_client, and any unfinished requests associated with
that client in the Pageant core will be cleaned up, so that you're
guaranteed that after the unregister operation, no stray callbacks
will happen with a stale pointer to that client.
The WM_COPYDATA interface of Windows Pageant is a direct client of
this API. The other client is PageantListener, the system that lives
in pageant.c and handles stream-based agent connections for both Unix
Pageant and the new Windows named-pipe IPC. More specifically, each
individual connection to the listening socket is a separate
PageantClient, which means that if a socket is closed abruptly or
suffers an OS error, that client can be unregistered and any pending
requests cancelled without disrupting other connections.
Users of PageantListener have a second client vtable they can use,
called PageantListenerClient. That contains _only_ logging facilities,
and at the moment, only Unix Pageant bothers to use it (and even that
only in debugging mode).
Finally, internally to the Pageant core, there's a new trait called
PageantAsyncOp which describes an agent request in the process of
being handled. But at the moment, it has only one trivial
implementation, which is handed the full response message already
constructed, and on the next toplevel callback, passes it back to the
PageantClient.
2020-01-25 17:24:28 +00:00
|
|
|
wmcpc.vt = &wmcpc_vtable;
|
|
|
|
wmcpc.suppress_logging = true;
|
|
|
|
pageant_register_client(&wmcpc);
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
DWORD wm_copydata_threadid;
|
|
|
|
wmct.ev_msg_ready = CreateEvent(NULL, false, false, NULL);
|
|
|
|
wmct.ev_reply_ready = CreateEvent(NULL, false, false, NULL);
|
|
|
|
CreateThread(NULL, 0, wm_copydata_threadfunc,
|
|
|
|
&inst, 0, &wm_copydata_threadid);
|
|
|
|
handle_add_foreign_event(wmct.ev_msg_ready, wm_copydata_got_msg, NULL);
|
|
|
|
|
2000-09-14 15:02:50 +00:00
|
|
|
/*
|
2000-09-15 10:48:42 +00:00
|
|
|
* Main message loop.
|
2000-09-14 15:02:50 +00:00
|
|
|
*/
|
2020-01-01 15:55:06 +00:00
|
|
|
while (true) {
|
|
|
|
HANDLE *handles;
|
|
|
|
int nhandles, n;
|
|
|
|
|
|
|
|
handles = handle_get_events(&nhandles);
|
|
|
|
|
|
|
|
n = MsgWaitForMultipleObjects(nhandles, handles, false,
|
|
|
|
INFINITE, QS_ALLINPUT);
|
|
|
|
|
|
|
|
if ((unsigned)(n - WAIT_OBJECT_0) < (unsigned)nhandles) {
|
|
|
|
handle_got_event(handles[n - WAIT_OBJECT_0]);
|
|
|
|
sfree(handles);
|
|
|
|
} else
|
|
|
|
sfree(handles);
|
|
|
|
|
|
|
|
while (PeekMessageW(&msg, NULL, 0, 0, PM_REMOVE)) {
|
|
|
|
if (msg.message == WM_QUIT)
|
|
|
|
goto finished; /* two-level break */
|
|
|
|
|
|
|
|
if (IsWindow(keylist) && IsDialogMessage(keylist, &msg))
|
|
|
|
continue;
|
|
|
|
if (IsWindow(aboutbox) && IsDialogMessage(aboutbox, &msg))
|
|
|
|
continue;
|
2020-03-21 15:59:51 +00:00
|
|
|
if (IsWindow(nonmodal_passphrase_hwnd) &&
|
|
|
|
IsDialogMessage(nonmodal_passphrase_hwnd, &msg))
|
|
|
|
continue;
|
2020-01-01 15:55:06 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
TranslateMessage(&msg);
|
|
|
|
DispatchMessage(&msg);
|
|
|
|
}
|
winpgnt: handle WM_COPYDATA requests in a subthread.
This is preparation to allow Pageant to be able to return to its GUI
main loop in the middle of handling a request (e.g. present a dialog
box to the user related to that particular request, and wait for the
user's response). In order to do that, we need the main thread's
Windows message loop to never be blocked by a WM_COPYDATA agent
request.
So I've split Pageant's previous hidden window into two hidden
windows, each with a subset of the original roles, and created in
different threads so that they get independent message loops. The one
in the main thread receives messages relating to Pageant's system tray
icon; the one in the subthread has the identity known to (old) Pageant
clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
handled by passing the request back to the main thread via an event
object integrated into the Pageant main loop, and then waiting for a
second event object that the main thread will signal when the answer
comes back, and not returning from the WndProc handler until the
response arrives.
Hence, if an agent request received via WM_COPYDATA requires GUI
activity, then the main thread's GUI message loop will be able to do
that in parallel with all Pageant's other activity, including other
GUI activity (like the key list dialog box) and including responding
to other requests via named pipe.
I can't stop WM_COPYDATA requests from blocking _each other_, but this
allows them not to block anything else. And named-pipe requests block
nothing at all, so as clients switch over to the new IPC, even that
blockage will become less and less common.
2020-01-25 17:24:17 +00:00
|
|
|
|
|
|
|
run_toplevel_callbacks();
|
2000-09-14 15:02:50 +00:00
|
|
|
}
|
2020-01-01 15:55:06 +00:00
|
|
|
finished:
|
2000-09-14 15:02:50 +00:00
|
|
|
|
|
|
|
/* Clean up the system tray icon */
|
|
|
|
{
|
2019-09-08 19:29:00 +00:00
|
|
|
NOTIFYICONDATA tnid;
|
2000-09-14 15:02:50 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
tnid.cbSize = sizeof(NOTIFYICONDATA);
|
2020-02-02 10:00:43 +00:00
|
|
|
tnid.hWnd = traywindow;
|
2019-09-08 19:29:00 +00:00
|
|
|
tnid.uID = 1;
|
2000-09-14 15:02:50 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
Shell_NotifyIcon(NIM_DELETE, &tnid);
|
2000-09-14 15:02:50 +00:00
|
|
|
|
2019-09-08 19:29:00 +00:00
|
|
|
DestroyMenu(systray_menu);
|
2000-09-14 15:02:50 +00:00
|
|
|
}
|
|
|
|
|
2005-02-28 02:40:43 +00:00
|
|
|
if (keypath) filereq_free(keypath);
|
|
|
|
|
2006-12-17 11:16:07 +00:00
|
|
|
cleanup_exit(msg.wParam);
|
2019-09-08 19:29:00 +00:00
|
|
|
return msg.wParam; /* just in case optimiser complains */
|
2000-09-14 15:02:50 +00:00
|
|
|
}
|