nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
pre-0.83
putty-source/unix/pageant.c

1541 lines
49 KiB
C
Raw Permalink Normal View History

Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
/*
* Unix Pageant, more or less similar to ssh-agent.
*/
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <assert.h>
#include <signal.h>
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
#include <ctype.h>
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
#include <sys/types.h>
#include <sys/wait.h>
Unix Pageant: add a --symlink option. I've often found it useful that you can make symlinks to Unix-domain sockets, and then connect() on the symlink path will redirect to the original socket. This commit adds an option to Unix Pageant which will make it symlink its socket path to a link location of your choice. My initial use case is when running Pageant in debug mode during development: if you run a new copy of it every few minutes after making a code change, then it's annoying to have it change its socket path every time so you have to keep pasting its setup command into your test shell. Not any more! Now you can run 'pageant --debug --symlink fixed-location', and then your test shell can point its SSH_AUTH_SOCK at the fixed location all the time. There are very likely other use cases too, but that's the one that motivated me to add the option.
2020-02-02 18:52:10 +00:00
#include <sys/stat.h>
Unix Pageant: -T option, tying lifetime to controlling tty. This is intended to be a useful mode when you want to run an ssh agent in a terminal session with no X11 available. You just execute a command along the lines of eval $(pageant -T), and then Pageant will run in the background for the rest of that terminal session - and when the terminal session ends, so that Pageant loses its controlling tty, it will take that as the signal to shut down. So, no need to manually kill it, and unlike 'pageant --exec $SHELL', you can also do this half way through a session if you don't realise until later that you need an SSH agent, without losing any shell command history or other shell context that you've accumulated so far in the session. Unfortunately, I haven't been able to find any reliable way to actually implement this -T mode, short of having Pageant wake up at regular intervals and try to open /dev/tty to see if it's still there. I had hoped that I could arrange to reliably get SIGHUP, or select on /dev/tty for exceptional conditions, or some such, but nothing I've tried along those lines seems to work.
2015-05-08 18:50:48 +00:00
#include <fcntl.h>
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
#include <unistd.h>
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
#include <termios.h>
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
#include "putty.h"
#include "ssh.h"
#include "misc.h"
#include "pageant.h"
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
void cmdline_error(const char *fmt, ...)
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
{
va_list ap;
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
va_start(ap, fmt);
console_print_error_msg_fmt_v("pageant", fmt, ap);
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
va_end(ap);
exit(1);
}
uxpgnt: factor out setup_sigchld_handler(). I'm about to need to call this from multiple places.
2020-02-08 18:35:37 +00:00
static void setup_sigchld_handler(void);
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
typedef enum RuntimePromptType {
RTPROMPT_UNAVAILABLE,
RTPROMPT_DEBUG,
RTPROMPT_GUI,
} RuntimePromptType;
static const char *progname;
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 uxpgnt_client {
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
FILE *logfp;
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
strbuf *prompt_buf;
RuntimePromptType prompt_type;
bool prompt_active;
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
PageantClientDialogId *dlgid;
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
int passphrase_fd;
int termination_pid;
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43: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
PageantListenerClient plc;
};
static void uxpgnt_log(PageantListenerClient *plc, const char *fmt, va_list ap)
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
{
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
struct uxpgnt_client *upc = container_of(plc, struct uxpgnt_client, plc);
if (!upc->logfp)
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
return;
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
fprintf(upc->logfp, "pageant: ");
vfprintf(upc->logfp, fmt, ap);
fprintf(upc->logfp, "\n");
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
}
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
static int make_pipe_to_askpass(const char *msg)
{
int pipefds[2];
setup_sigchld_handler();
if (pipe(pipefds) < 0)
return -1;
pid_t pid = fork();
if (pid < 0) {
close(pipefds[0]);
close(pipefds[1]);
return -1;
}
if (pid == 0) {
const char *args[5] = {
progname, "--gui-prompt", "--askpass", msg, NULL
};
dup2(pipefds[1], 1);
cloexec(pipefds[0]);
cloexec(pipefds[1]);
/*
Update source file names in comments and docs. Correcting a source file name in the docs just now reminded me that I've seen a lot of outdated source file names elsewhere in the code, due to all the reorganisation since we moved to cmake. Here's a giant pass of trying to make them all accurate again.
2022-01-22 15:38:53 +00:00
* See comment in fork_and_exec_self() in main-gtk-simple.c.
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
*/
execv("/proc/self/exe", (char **)args);
execvp(progname, (char **)args);
perror("exec");
_exit(127);
}
close(pipefds[1]);
return pipefds[0];
}
Pageant: introduce an API for passphrase prompts. This begins to head towards the goal of storing a key file encrypted in Pageant, and decrypting it on demand via a GUI prompt the first time a client requests a signature from it. That won't be a facility available in all situations, so we have to be able to return failure from the prompt. More precisely, there are two versions of this API, one in PageantClient and one in PageantListenerClient: the stream implementation of PageantClient implements the former API and hands it off to the latter. Windows Pageant has to directly implement both (but they will end up funnelling to the same function within winpgnt.c). NFC: for the moment, the new API functions are never called, and every implementation of them returns failure.
2020-01-20 21:22:33 +00:00
static bool uxpgnt_ask_passphrase(
Polish up passphrase prompts for key decryption. Now Windows Pageant has two clearly distinct dialog boxes for requesting a key passphrase: one to use synchronously when the user has just used the 'Add Key' GUI action, and one to use asynchronously in response to an agent client's attempt to use a key that was loaded encrypted. Also fixed the wording in the asynchronous box: there were two copies of the 'enter passphrase' instruction, one from the dialog definition in pageant.rc file and one from the cross-platform pageant.c. Now pageant.c doesn't format a whole user-facing message any more: it leaves that to the platform front end to do it the way it wants. I've also added a call to SetForegroundWindow, to try to get the passphrase prompt into the foreground. In my experience this doesn't actually get it the keyboard focus, which I think is deliberate on Windows's part and there's nothing I can do about it. But at least the user should _see_ that the prompt is there, so they can focus it themself.
2021-04-02 09:49:18 +00:00
PageantListenerClient *plc, PageantClientDialogId *dlgid,
const char *comment)
Pageant: introduce an API for passphrase prompts. This begins to head towards the goal of storing a key file encrypted in Pageant, and decrypting it on demand via a GUI prompt the first time a client requests a signature from it. That won't be a facility available in all situations, so we have to be able to return failure from the prompt. More precisely, there are two versions of this API, one in PageantClient and one in PageantListenerClient: the stream implementation of PageantClient implements the former API and hands it off to the latter. Windows Pageant has to directly implement both (but they will end up funnelling to the same function within winpgnt.c). NFC: for the moment, the new API functions are never called, and every implementation of them returns failure.
2020-01-20 21:22:33 +00:00
{
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
struct uxpgnt_client *upc = container_of(plc, struct uxpgnt_client, plc);
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
assert(!upc->dlgid); /* Pageant core should be serialising requests */
Polish up passphrase prompts for key decryption. Now Windows Pageant has two clearly distinct dialog boxes for requesting a key passphrase: one to use synchronously when the user has just used the 'Add Key' GUI action, and one to use asynchronously in response to an agent client's attempt to use a key that was loaded encrypted. Also fixed the wording in the asynchronous box: there were two copies of the 'enter passphrase' instruction, one from the dialog definition in pageant.rc file and one from the cross-platform pageant.c. Now pageant.c doesn't format a whole user-facing message any more: it leaves that to the platform front end to do it the way it wants. I've also added a call to SetForegroundWindow, to try to get the passphrase prompt into the foreground. In my experience this doesn't actually get it the keyboard focus, which I think is deliberate on Windows's part and there's nothing I can do about it. But at least the user should _see_ that the prompt is there, so they can focus it themself.
2021-04-02 09:49:18 +00:00
char *msg = dupprintf(
"A client of Pageant wants to use the following encrypted key:\n"
"%s\n"
"If you intended this, enter the passphrase to decrypt the key.",
comment);
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
switch (upc->prompt_type) {
case RTPROMPT_UNAVAILABLE:
Polish up passphrase prompts for key decryption. Now Windows Pageant has two clearly distinct dialog boxes for requesting a key passphrase: one to use synchronously when the user has just used the 'Add Key' GUI action, and one to use asynchronously in response to an agent client's attempt to use a key that was loaded encrypted. Also fixed the wording in the asynchronous box: there were two copies of the 'enter passphrase' instruction, one from the dialog definition in pageant.rc file and one from the cross-platform pageant.c. Now pageant.c doesn't format a whole user-facing message any more: it leaves that to the platform front end to do it the way it wants. I've also added a call to SetForegroundWindow, to try to get the passphrase prompt into the foreground. In my experience this doesn't actually get it the keyboard focus, which I think is deliberate on Windows's part and there's nothing I can do about it. But at least the user should _see_ that the prompt is there, so they can focus it themself.
2021-04-02 09:49:18 +00:00
sfree(msg);
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
return false;
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
case RTPROMPT_GUI:
upc->passphrase_fd = make_pipe_to_askpass(msg);
Polish up passphrase prompts for key decryption. Now Windows Pageant has two clearly distinct dialog boxes for requesting a key passphrase: one to use synchronously when the user has just used the 'Add Key' GUI action, and one to use asynchronously in response to an agent client's attempt to use a key that was loaded encrypted. Also fixed the wording in the asynchronous box: there were two copies of the 'enter passphrase' instruction, one from the dialog definition in pageant.rc file and one from the cross-platform pageant.c. Now pageant.c doesn't format a whole user-facing message any more: it leaves that to the platform front end to do it the way it wants. I've also added a call to SetForegroundWindow, to try to get the passphrase prompt into the foreground. In my experience this doesn't actually get it the keyboard focus, which I think is deliberate on Windows's part and there's nothing I can do about it. But at least the user should _see_ that the prompt is there, so they can focus it themself.
2021-04-02 09:49:18 +00:00
sfree(msg);
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
if (upc->passphrase_fd < 0)
return false; /* something went wrong */
break;
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
case RTPROMPT_DEBUG:
fprintf(upc->logfp, "pageant passphrase request: %s\n", msg);
Polish up passphrase prompts for key decryption. Now Windows Pageant has two clearly distinct dialog boxes for requesting a key passphrase: one to use synchronously when the user has just used the 'Add Key' GUI action, and one to use asynchronously in response to an agent client's attempt to use a key that was loaded encrypted. Also fixed the wording in the asynchronous box: there were two copies of the 'enter passphrase' instruction, one from the dialog definition in pageant.rc file and one from the cross-platform pageant.c. Now pageant.c doesn't format a whole user-facing message any more: it leaves that to the platform front end to do it the way it wants. I've also added a call to SetForegroundWindow, to try to get the passphrase prompt into the foreground. In my experience this doesn't actually get it the keyboard focus, which I think is deliberate on Windows's part and there's nothing I can do about it. But at least the user should _see_ that the prompt is there, so they can focus it themself.
2021-04-02 09:49:18 +00:00
sfree(msg);
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
break;
}
upc->prompt_active = true;
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
upc->dlgid = dlgid;
return true;
}
static void passphrase_done(struct uxpgnt_client *upc, bool success)
{
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
PageantClientDialogId *dlgid = upc->dlgid;
upc->dlgid = NULL;
upc->prompt_active = false;
if (upc->logfp)
fprintf(upc->logfp, "pageant passphrase response: %s\n",
success ? "success" : "failure");
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
if (success)
pageant_passphrase_request_success(
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
dlgid, ptrlen_from_strbuf(upc->prompt_buf));
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
else
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
pageant_passphrase_request_refused(dlgid);
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
strbuf_free(upc->prompt_buf);
upc->prompt_buf = strbuf_new_nm();
Pageant: introduce an API for passphrase prompts. This begins to head towards the goal of storing a key file encrypted in Pageant, and decrypting it on demand via a GUI prompt the first time a client requests a signature from it. That won't be a facility available in all situations, so we have to be able to return failure from the prompt. More precisely, there are two versions of this API, one in PageantClient and one in PageantListenerClient: the stream implementation of PageantClient implements the former API and hands it off to the latter. Windows Pageant has to directly implement both (but they will end up funnelling to the same function within winpgnt.c). NFC: for the moment, the new API functions are never called, and every implementation of them returns failure.
2020-01-20 21:22:33 +00:00
}
Add lots of missing 'static' keywords. A trawl through the code with -Wmissing-prototypes and -Wmissing-variable-declarations turned up a lot of things that should have been internal to a particular source file, but were accidentally global. Keep the namespace clean by making them all static. (Also, while I'm here, a couple of them were missing a 'const': the ONE and ZERO arrays in sshcrcda.c, and EMPTY_WINDOW_TITLE in terminal.c.)
2020-01-29 06:22:01 +00:00
static const PageantListenerClientVtable uxpgnt_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 = uxpgnt_log,
.ask_passphrase = uxpgnt_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
};
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
/*
* More stubs.
*/
void random_save_seed(void) {}
void random_destroy_seed(void) {}
char *platform_default_s(const char *name) { return NULL; }
Switch some Conf settings over to being bool. I think this is the full set of things that ought logically to be boolean. One annoyance is that quite a few radio-button controls in config.c address Conf fields that are now bool rather than int, which means that the shared handler function can't just access them all with conf_{get,set}_int. Rather than back out the rigorous separation of int and bool in conf.c itself, I've just added a similar alternative handler function for the bool-typed ones.
2018-10-29 19:57:31 +00:00
bool platform_default_b(const char *name, bool def) { return def; }
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
int platform_default_i(const char *name, int def) { return def; }
Add platform-independent fontspec_new_default() function. Constructing a FontSpec in platform-independent code is awkward, because you can't call fontspec_new() outside the platform subdirs (since its prototype varies per platform). But sometimes you just need _some_ valid FontSpec, e.g. to put in a Conf that will be used in some place where you don't actually care about font settings, such as a purely CLI program. Both Unix and Windows _have_ an idiom for this, but they're different, because their FontSpec constructors have different prototypes. The existing CLI tools have always had per-platform main source files, so they just use the locally appropriate method of constructing a boring don't-care FontSpec. But if you want a _platform-independent_ main source file, such as you might find in a test program, then that's rather awkward. Better to have a platform-independent API for making a default FontSpec.
2023-02-18 13:43:50 +00:00
FontSpec *platform_default_fontspec(const char *name) { return fontspec_new_default(); }
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
Filename *platform_default_filename(const char *name) { return filename_from_str(""); }
char *x_get_default(const char *key) { return NULL; }
/*
* Short description of parameters.
*/
static void usage(void)
{
printf("Pageant: SSH agent\n");
printf("%s\n", ver);
Pageant: docs / help for deferred decryption. Also, ensure -E/--fptype in Unix Pageant is (correctly) documented everywhere.
2021-04-05 17:35:38 +00:00
printf("Usage: pageant <lifetime> [[--encrypted] key files]\n");
printf(" pageant [[--encrypted] key files] --exec <command> [args]\n");
printf(" pageant -a [--encrypted] [key files]\n");
Unix Pageant: man page and online help. I think Unix Pageant is now more or less usable, though of course I wouldn't blame anyone for sticking with other SSH agent solutions.
2015-05-19 17:24:04 +00:00
printf(" pageant -d [key identifiers]\n");
Pageant: docs / help for deferred decryption. Also, ensure -E/--fptype in Unix Pageant is (correctly) documented everywhere.
2021-04-05 17:35:38 +00:00
printf(" pageant -D\n");
printf(" pageant -r [key identifiers]\n");
printf(" pageant -R\n");
Unix Pageant: man page and online help. I think Unix Pageant is now more or less usable, though of course I wouldn't blame anyone for sticking with other SSH agent solutions.
2015-05-19 17:24:04 +00:00
printf(" pageant --public [key identifiers]\n");
Unix Pageant: add alias '-L' for '--private-openssh'. Matches the -L option in Unix PuTTYgen, and is much easier to type.
2018-06-03 14:38:57 +00:00
printf(" pageant ( --public-openssh | -L ) [key identifiers]\n");
Pageant: docs / help for deferred decryption. Also, ensure -E/--fptype in Unix Pageant is (correctly) documented everywhere.
2021-04-05 17:35:38 +00:00
printf(" pageant -l [-E fptype]\n");
Unix Pageant: man page and online help. I think Unix Pageant is now more or less usable, though of course I wouldn't blame anyone for sticking with other SSH agent solutions.
2015-05-19 17:24:04 +00:00
printf("Lifetime options, for running Pageant as an agent:\n");
printf(" -X run with the lifetime of the X server\n");
printf(" -T run with the lifetime of the controlling tty\n");
printf(" --permanent run permanently\n");
printf(" --debug run in debugging mode, without forking\n");
Support running UNIX Pageant in foreground mode, without debugging output This new mode makes it easy to run Pageant as a "supervised" instance, e.g. as part of a test harness for other programs interacting with an SSH agent, which is the original use case. Because Pageant is then running as a child process of the supervisor, the operating system notifies the supervisor of the child's aliveness without resorting to PIDs or socket addresses, both of which may principally run stale and/or get recycled.
2024-09-18 18:04:31 +00:00
printf(" --foreground run permanently, without forking\n");
Unix Pageant: man page and online help. I think Unix Pageant is now more or less usable, though of course I wouldn't blame anyone for sticking with other SSH agent solutions.
2015-05-19 17:24:04 +00:00
printf(" --exec <command> run with the lifetime of that command\n");
printf("Client options, for talking to an existing agent:\n");
printf(" -a add key(s) to the existing agent\n");
printf(" -l list currently loaded key fingerprints and comments\n");
printf(" --public print public keys in RFC 4716 format\n");
Unix Pageant: add alias '-L' for '--private-openssh'. Matches the -L option in Unix PuTTYgen, and is much easier to type.
2018-06-03 14:38:57 +00:00
printf(" --public-openssh, -L print public keys in OpenSSH format\n");
Unix Pageant: man page and online help. I think Unix Pageant is now more or less usable, though of course I wouldn't blame anyone for sticking with other SSH agent solutions.
2015-05-19 17:24:04 +00:00
printf(" -d delete key(s) from the agent\n");
printf(" -D delete all keys from the agent\n");
Fix missing parenthesis in help text.
2022-01-06 23:50:44 +00:00
printf(" -r re-encrypt keys in the agent (forget cleartext)\n");
Pageant: docs / help for deferred decryption. Also, ensure -E/--fptype in Unix Pageant is (correctly) documented everywhere.
2021-04-05 17:35:38 +00:00
printf(" -R re-encrypt all possible keys in the agent\n");
Unix Pageant: man page and online help. I think Unix Pageant is now more or less usable, though of course I wouldn't blame anyone for sticking with other SSH agent solutions.
2015-05-19 17:24:04 +00:00
printf("Other options:\n");
printf(" -v verbose mode (in agent mode)\n");
Add -c/-s to Unix 'pageant --help'.
2017-02-11 22:12:33 +00:00
printf(" -s -c force POSIX or C shell syntax (in agent mode)\n");
uxpgnt: Briefly document --symlink and --test-sign.
2021-04-19 14:40:35 +00:00
printf(" --symlink path create symlink to socket (in agent mode)\n");
Pageant: docs / help for deferred decryption. Also, ensure -E/--fptype in Unix Pageant is (correctly) documented everywhere.
2021-04-05 17:35:38 +00:00
printf(" --encrypted when adding keys, don't decrypt\n");
printf(" -E alg, --fptype alg fingerprint type for -l (sha256, md5)\n");
Unix pageant usage: --foo-prompt not just for -a.
2021-04-05 11:47:38 +00:00
printf(" --tty-prompt force tty-based passphrase prompt\n");
printf(" --gui-prompt force GUI-based passphrase prompt\n");
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
printf(" --askpass <prompt> behave like a standalone askpass program\n");
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
}
static void version(void)
{
Include 'build info' in all --version text and About boxes. This shows the build platform (32- vs 64-bit in particular, and also whether Unix GTK builds were compiled with or without the X11 pieces), what compiler was used to build the binary, and any interesting build options that might have been set on the make command line (especially, but not limited to, the security-damaging ones like NO_SECURITY or UNPROTECT). This will probably be useful all over the place, but in particular it should allow the different Windows binaries to be told apart! Commits 21101c739 and 2eb952ca3 laid the groundwork for this, by allowing the various About boxes to contain free text and also ensuring they could be copied and pasted easily as part of a bug report.
2017-01-21 14:55:53 +00:00
char *buildinfo_text = buildinfo("\n");
printf("pageant: %s\n%s\n", ver, buildinfo_text);
sfree(buildinfo_text);
Return zero when reporting our version. When called with -V to ask for our version, return 0 rather than 1. This is the usual behaviour observed by ssh(1) and other Unix commands. Also use exit() rather than cleanup_exit() in pscp.c and psftp.c ; at this point we have nothing to cleanup!
2017-02-15 19:50:14 +00:00
exit(0);
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
}
void keylist_update(void)
{
/* Nothing needs doing in Unix Pageant */
}
#define PAGEANT_DIR_PREFIX "/tmp/pageant"
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 time_to_die = false;
Clean up Unix Pageant's setup and teardown. I've moved the listening socket setup back to before the lifetime preparations, so in particular we find out that we couldn't bind to the socket _before_ we fork. The only part that really needed to come after lifetime setup was the logging setup, so that's now a separate function called later. Also, the random exit(0)s in silly places like x11_closing have turned into setting a time_to_die flag, so that all clean exits funnel back to the end of main() which at least tries to tidy up a bit afterwards. (Finally, fixed a small bug in testing the return value of waitpid(), which only showed up once we didn't exit(0) after the first wait. Ahem.)
2015-05-07 18:04:25 +00:00
New API for plug_closing() with a custom type enum. Passing an operating-system-specific error code to plug_closing(), such as errno or GetLastError(), was always a bit weird, given that it generally had to be handled by cross-platform receiving code in backends. I had the platform.h implementations #define any error values that the cross-platform code would have to handle specially, but that's still not a great system, because it also doesn't leave freedom to invent error representations of my own that don't correspond to any OS code. (For example, the ones I just removed from proxy.h.) So now, the OS error code is gone from the plug_closing API, and in its place is a custom enumeration of closure types: normal, error, and the special case BROKEN_PIPE which is the only OS error code we have so far needed to handle specially. (All others just mean 'abandon the connection and print the textual message'.) Having already centralised the handling of OS error codes in the previous commit, we've now got a convenient place to add any further type codes for errors needing special handling: each of Unix plug_closing_errno(), Windows plug_closing_system_error(), and Windows plug_closing_winsock_error() can easily grow extra special cases if need be, and each one will only have to live in one place.
2021-11-06 13:28:32 +00:00
static void x11_closing(Plug *plug, PlugCloseType type, const char *error_msg)
Clean up Unix Pageant's setup and teardown. I've moved the listening socket setup back to before the lifetime preparations, so in particular we find out that we couldn't bind to the socket _before_ we fork. The only part that really needed to come after lifetime setup was the logging setup, so that's now a separate function called later. Also, the random exit(0)s in silly places like x11_closing have turned into setting a time_to_die flag, so that all clean exits funnel back to the end of main() which at least tries to tidy up a bit afterwards. (Finally, fixed a small bug in testing the return value of waitpid(), which only showed up once we didn't exit(0) after the first wait. Ahem.)
2015-05-07 18:04:25 +00:00
{
Centralise stub plug/socket functions. In the previous few commits I noticed some repeated work in the form of pointless empty implementations of Plug's log method, plus some existing (and some new) empty cases of Socket's endpoint_info. As a cleanup, I'm replacing as many as I can find with uses of a central null implementation in the stubs directory.
2024-06-29 11:07:59 +00:00
/*
* When the X connection closes, signal back to the main loop that
* it's time to terminate.
*/
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
time_to_die = true;
Clean up Unix Pageant's setup and teardown. I've moved the listening socket setup back to before the lifetime preparations, so in particular we find out that we couldn't bind to the socket _before_ we fork. The only part that really needed to come after lifetime setup was the logging setup, so that's now a separate function called later. Also, the random exit(0)s in silly places like x11_closing have turned into setting a time_to_die flag, so that all clean exits funnel back to the end of main() which at least tries to tidy up a bit afterwards. (Finally, fixed a small bug in testing the return value of waitpid(), which only showed up once we didn't exit(0) after the first wait. Ahem.)
2015-05-07 18:04:25 +00:00
}
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
struct X11Connection {
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
Plug plug;
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
};
Make more file-scope variables static. In the previous trawl of this, I didn't bother with the statics in main-program modules, on the grounds that my main aim was to avoid 'library' objects (shared between multiple programs) from polluting the global namespace. But I think it's worth being more strict after all, so this commit adds 'static' to a lot more file-scope variables that aren't needed outside their own module.
2020-02-02 10:00:43 +00:00
static char *socketname;
Support sh/csh syntax switching for Unix Pageant.
2016-03-25 16:43:59 +00:00
static enum { SHELL_AUTO, SHELL_SH, SHELL_CSH } shell_type = SHELL_AUTO;
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
void pageant_print_env(int pid)
{
Support sh/csh syntax switching for Unix Pageant.
2016-03-25 16:43:59 +00:00
if (shell_type == SHELL_AUTO) {
/* Same policy as OpenSSH: if $SHELL ends in "csh" then assume
* it's csh-shaped. */
const char *shell = getenv("SHELL");
if (shell && strlen(shell) >= 3 &&
!strcmp(shell + strlen(shell) - 3, "csh"))
shell_type = SHELL_CSH;
else
shell_type = SHELL_SH;
}
/*
* These shell snippets could usefully pay some attention to
* escaping of interesting characters. I don't think it causes a
* problem at the moment, because the pathnames we use are so
* utterly boring, but it's a lurking bug waiting to happen once
* a bit more flexibility turns up.
*/
switch (shell_type) {
case SHELL_SH:
printf("SSH_AUTH_SOCK=%s; export SSH_AUTH_SOCK;\n"
"SSH_AGENT_PID=%d; export SSH_AGENT_PID;\n",
socketname, pid);
break;
case SHELL_CSH:
printf("setenv SSH_AUTH_SOCK %s;\n"
"setenv SSH_AGENT_PID %d;\n",
socketname, pid);
break;
case SHELL_AUTO:
Replace assert(false) with an unreachable() macro. Taking a leaf out of the LLVM code base: this macro still includes an assert(false) so that the message will show up in a typical build, but it follows it up with a call to a function explicitly marked as no- return. So this ought to do a better job of convincing compilers that once a code path hits this function it _really doesn't_ have to still faff about with making up a bogus return value or filling in a variable that 'might be used uninitialised' in the following code that won't be reached anyway. I've gone through the existing code looking for the assert(false) / assert(0) idiom and replaced all the ones I found with the new macro, which also meant I could remove a few pointless return statements and variable initialisations that I'd already had to put in to placate compiler front ends.
2019-01-03 08:12:19 +00:00
unreachable("SHELL_AUTO should have been eliminated by now");
Support sh/csh syntax switching for Unix Pageant.
2016-03-25 16:43:59 +00:00
break;
}
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +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
void pageant_fork_and_print_env(bool retain_tty)
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
{
pid_t pid = fork();
if (pid == -1) {
perror("fork");
exit(1);
} else if (pid != 0) {
pageant_print_env(pid);
exit(0);
}
/*
* Having forked off, we now daemonise ourselves as best we can.
* It's good practice in general to setsid() ourself out of any
* process group we didn't want to be part of, and to chdir("/")
* to avoid holding any directories open that we don't need in
* case someone wants to umount them; also, we should definitely
* close standard output (because it will very likely be pointing
* at a pipe from which some parent process is trying to read our
* environment variable dump, so if we hold open another copy of
* it then that process will never finish reading). We close
* standard input too on general principles, but not standard
* error, since we might need to shout a panicky error message
* down that one.
*/
if (chdir("/") < 0) {
/* should there be an error condition, nothing we can do about
* it anyway */
}
close(0);
close(1);
Unix Pageant: -T option, tying lifetime to controlling tty. This is intended to be a useful mode when you want to run an ssh agent in a terminal session with no X11 available. You just execute a command along the lines of eval $(pageant -T), and then Pageant will run in the background for the rest of that terminal session - and when the terminal session ends, so that Pageant loses its controlling tty, it will take that as the signal to shut down. So, no need to manually kill it, and unlike 'pageant --exec $SHELL', you can also do this half way through a session if you don't realise until later that you need an SSH agent, without losing any shell command history or other shell context that you've accumulated so far in the session. Unfortunately, I haven't been able to find any reliable way to actually implement this -T mode, short of having Pageant wake up at regular intervals and try to open /dev/tty to see if it's still there. I had hoped that I could arrange to reliably get SIGHUP, or select on /dev/tty for exceptional conditions, or some such, but nothing I've tried along those lines seems to work.
2015-05-08 18:50:48 +00:00
if (retain_tty) {
/* Get out of our previous process group, to avoid being
* blasted by passing signals. But keep our controlling tty,
* so we can keep checking to see if we still have one. */
setpgrp cmake check: use #if, not #if defined. I still haven't got out of the habit of doing this the autotools way, which doesn't work in cmake. cmake's HAVE_FOO variables are always defined, and they take values 0 or 1, so testing them with 'defined' will return the wrong value.
2022-09-19 11:31:27 +00:00
#if HAVE_NULLARY_SETPGRP
Unix Pageant: -T option, tying lifetime to controlling tty. This is intended to be a useful mode when you want to run an ssh agent in a terminal session with no X11 available. You just execute a command along the lines of eval $(pageant -T), and then Pageant will run in the background for the rest of that terminal session - and when the terminal session ends, so that Pageant loses its controlling tty, it will take that as the signal to shut down. So, no need to manually kill it, and unlike 'pageant --exec $SHELL', you can also do this half way through a session if you don't realise until later that you need an SSH agent, without losing any shell command history or other shell context that you've accumulated so far in the session. Unfortunately, I haven't been able to find any reliable way to actually implement this -T mode, short of having Pageant wake up at regular intervals and try to open /dev/tty to see if it's still there. I had hoped that I could arrange to reliably get SIGHUP, or select on /dev/tty for exceptional conditions, or some such, but nothing I've tried along those lines seems to work.
2015-05-08 18:50:48 +00:00
setpgrp();
setpgrp cmake check: use #if, not #if defined. I still haven't got out of the habit of doing this the autotools way, which doesn't work in cmake. cmake's HAVE_FOO variables are always defined, and they take values 0 or 1, so testing them with 'defined' will return the wrong value.
2022-09-19 11:31:27 +00:00
#elif HAVE_BINARY_SETPGRP
Add cmake check for whether setpgrp takes arguments. FreeBSD declares setpgrp() as taking two arguments, like Linux's setpgid(). Detect that at configure time and adjust the call in Pageant appropriately.
2022-09-18 14:08:31 +00:00
setpgrp(0, 0);
#endif
Unix Pageant: -T option, tying lifetime to controlling tty. This is intended to be a useful mode when you want to run an ssh agent in a terminal session with no X11 available. You just execute a command along the lines of eval $(pageant -T), and then Pageant will run in the background for the rest of that terminal session - and when the terminal session ends, so that Pageant loses its controlling tty, it will take that as the signal to shut down. So, no need to manually kill it, and unlike 'pageant --exec $SHELL', you can also do this half way through a session if you don't realise until later that you need an SSH agent, without losing any shell command history or other shell context that you've accumulated so far in the session. Unfortunately, I haven't been able to find any reliable way to actually implement this -T mode, short of having Pageant wake up at regular intervals and try to open /dev/tty to see if it's still there. I had hoped that I could arrange to reliably get SIGHUP, or select on /dev/tty for exceptional conditions, or some such, but nothing I've tried along those lines seems to work.
2015-05-08 18:50:48 +00:00
} else {
/* Do that, but also leave our entire session and detach from
* the controlling tty (if any). */
setsid();
}
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
}
uxpgnt: factor out setup_sigchld_handler(). I'm about to need to call this from multiple places.
2020-02-08 18:35:37 +00:00
static int signalpipe[2] = { -1, -1 };
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
uxpgnt: factor out setup_sigchld_handler(). I'm about to need to call this from multiple places.
2020-02-08 18:35:37 +00:00
static void sigchld(int signum)
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
{
if (write(signalpipe[1], "x", 1) <= 0)
/* not much we can do about it */;
}
uxpgnt: factor out setup_sigchld_handler(). I'm about to need to call this from multiple places.
2020-02-08 18:35:37 +00:00
static void setup_sigchld_handler(void)
{
if (signalpipe[0] >= 0)
return;
/*
* Set up the pipe we'll use to tell us about SIGCHLD.
*/
if (pipe(signalpipe) < 0) {
perror("pipe");
exit(1);
}
putty_signal(SIGCHLD, sigchld);
}
Unix Pageant: -T option, tying lifetime to controlling tty. This is intended to be a useful mode when you want to run an ssh agent in a terminal session with no X11 available. You just execute a command along the lines of eval $(pageant -T), and then Pageant will run in the background for the rest of that terminal session - and when the terminal session ends, so that Pageant loses its controlling tty, it will take that as the signal to shut down. So, no need to manually kill it, and unlike 'pageant --exec $SHELL', you can also do this half way through a session if you don't realise until later that you need an SSH agent, without losing any shell command history or other shell context that you've accumulated so far in the session. Unfortunately, I haven't been able to find any reliable way to actually implement this -T mode, short of having Pageant wake up at regular intervals and try to open /dev/tty to see if it's still there. I had hoped that I could arrange to reliably get SIGHUP, or select on /dev/tty for exceptional conditions, or some such, but nothing I've tried along those lines seems to work.
2015-05-08 18:50:48 +00:00
#define TTY_LIFE_POLL_INTERVAL (TICKSPERSEC * 30)
Make more file-scope variables static. In the previous trawl of this, I didn't bother with the statics in main-program modules, on the grounds that my main aim was to avoid 'library' objects (shared between multiple programs) from polluting the global namespace. But I think it's worth being more strict after all, so this commit adds 'static' to a lot more file-scope variables that aren't needed outside their own module.
2020-02-02 10:00:43 +00:00
static void *dummy_timer_ctx;
Unix Pageant: -T option, tying lifetime to controlling tty. This is intended to be a useful mode when you want to run an ssh agent in a terminal session with no X11 available. You just execute a command along the lines of eval $(pageant -T), and then Pageant will run in the background for the rest of that terminal session - and when the terminal session ends, so that Pageant loses its controlling tty, it will take that as the signal to shut down. So, no need to manually kill it, and unlike 'pageant --exec $SHELL', you can also do this half way through a session if you don't realise until later that you need an SSH agent, without losing any shell command history or other shell context that you've accumulated so far in the session. Unfortunately, I haven't been able to find any reliable way to actually implement this -T mode, short of having Pageant wake up at regular intervals and try to open /dev/tty to see if it's still there. I had hoped that I could arrange to reliably get SIGHUP, or select on /dev/tty for exceptional conditions, or some such, but nothing I've tried along those lines seems to work.
2015-05-08 18:50:48 +00:00
static void tty_life_timer(void *ctx, unsigned long now)
{
schedule_timer(TTY_LIFE_POLL_INTERVAL, tty_life_timer, &dummy_timer_ctx);
}
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
typedef enum {
KEYACT_AGENT_LOAD,
Unix Pageant: -E option to load key files encrypted. This applies to both server modes ('pageant -E key.ppk [lifetime]') and client mode ('pageant -a -E key.ppk'). I'm not completely confident that the CLI syntax is actually right yet, but for the moment, it's enough that it _exists_. Now I don't have to test the encrypted-key loading via manually mocked-up agent requests.
2020-02-08 17:28:46 +00:00
KEYACT_AGENT_LOAD_ENCRYPTED,
KEYACT_CLIENT_BASE,
KEYACT_CLIENT_ADD = KEYACT_CLIENT_BASE,
KEYACT_CLIENT_ADD_ENCRYPTED,
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
KEYACT_CLIENT_DEL,
KEYACT_CLIENT_DEL_ALL,
KEYACT_CLIENT_LIST,
Unix Pageant: provide public-key extraction options. I've decided against implementing an option exactly analogous to 'ssh-add -L' (printing the full public key of everything in the agent). Instead, you can identify a specific key to display in full, by any of the same means -d lets you use, and then print it in either of the public key formats we support.
2015-05-12 13:48:32 +00:00
KEYACT_CLIENT_PUBLIC_OPENSSH,
Unix Pageant: --test-sign client option. This reads data from standard input, turns it into an SSH-2 sign request, and writes the resulting signature blob to standard output. I don't really anticipate many uses for this other than testing. But it _is_ convenient for testing changes to Pageant itself: it lets me ask for a signature without first having to construct a pointless SSH session that will accept the relevant key.
2020-02-09 21:56:21 +00:00
KEYACT_CLIENT_PUBLIC,
KEYACT_CLIENT_SIGN,
Unix Pageant: support -r and -R options to re-encrypt. This links up the new re-encryption facilities to the Unix Pageant client-mode command line. Analogously to -d and -D, 'pageant -r key-id' re-encrypts a single key, and 'pageant -R' re-encrypts everything.
2020-02-15 16:40:19 +00:00
KEYACT_CLIENT_REENCRYPT,
KEYACT_CLIENT_REENCRYPT_ALL,
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
} keyact;
struct cmdline_key_action {
struct cmdline_key_action *next;
keyact action;
const char *filename;
};
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 is_agent_action(keyact action)
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
{
Unix Pageant: -E option to load key files encrypted. This applies to both server modes ('pageant -E key.ppk [lifetime]') and client mode ('pageant -a -E key.ppk'). I'm not completely confident that the CLI syntax is actually right yet, but for the moment, it's enough that it _exists_. Now I don't have to test the encrypted-key loading via manually mocked-up agent requests.
2020-02-08 17:28:46 +00:00
return action < KEYACT_CLIENT_BASE;
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
}
Make more file-scope variables static. In the previous trawl of this, I didn't bother with the statics in main-program modules, on the grounds that my main aim was to avoid 'library' objects (shared between multiple programs) from polluting the global namespace. But I think it's worth being more strict after all, so this commit adds 'static' to a lot more file-scope variables that aren't needed outside their own module.
2020-02-02 10:00:43 +00:00
static struct cmdline_key_action *keyact_head = NULL, *keyact_tail = NULL;
Unix Pageant: --test-sign client option. This reads data from standard input, turns it into an SSH-2 sign request, and writes the resulting signature blob to standard output. I don't really anticipate many uses for this other than testing. But it _is_ convenient for testing changes to Pageant itself: it lets me ask for a signature without first having to construct a pointless SSH session that will accept the relevant key.
2020-02-09 21:56:21 +00:00
static uint32_t sign_flags = 0;
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
void add_keyact(keyact action, const char *filename)
{
struct cmdline_key_action *a = snew(struct cmdline_key_action);
a->action = action;
a->filename = filename;
a->next = NULL;
if (keyact_tail)
keyact_tail->next = a;
else
keyact_head = a;
keyact_tail = a;
}
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 have_controlling_tty(void)
Unix Pageant: factor out have_controlling_tty(). I'm going to want to reuse it when deciding on a passphrase-prompting strategy.
2015-05-13 12:54:15 +00:00
{
int fd = open("/dev/tty", O_RDONLY);
if (fd < 0) {
if (errno != ENXIO) {
perror("/dev/tty: open");
exit(1);
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Unix Pageant: factor out have_controlling_tty(). I'm going to want to reuse it when deciding on a passphrase-prompting strategy.
2015-05-13 12:54:15 +00:00
} else {
close(fd);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Unix Pageant: factor out have_controlling_tty(). I'm going to want to reuse it when deciding on a passphrase-prompting strategy.
2015-05-13 12:54:15 +00:00
}
}
Make more file-scope variables static. In the previous trawl of this, I didn't bother with the statics in main-program modules, on the grounds that my main aim was to avoid 'library' objects (shared between multiple programs) from polluting the global namespace. But I think it's worth being more strict after all, so this commit adds 'static' to a lot more file-scope variables that aren't needed outside their own module.
2020-02-02 10:00:43 +00:00
static char **exec_args = NULL;
static enum {
Support running UNIX Pageant in foreground mode, without debugging output This new mode makes it easy to run Pageant as a "supervised" instance, e.g. as part of a test harness for other programs interacting with an SSH agent, which is the original use case. Because Pageant is then running as a child process of the supervisor, the operating system notifies the supervisor of the child's aliveness without resorting to PIDs or socket addresses, both of which may principally run stale and/or get recycled.
2024-09-18 18:04:31 +00:00
LIFE_UNSPEC, LIFE_X11, LIFE_TTY, LIFE_DEBUG, LIFE_PERM, LIFE_EXEC, LIFE_FOREGROUND
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
} life = LIFE_UNSPEC;
Make more file-scope variables static. In the previous trawl of this, I didn't bother with the statics in main-program modules, on the grounds that my main aim was to avoid 'library' objects (shared between multiple programs) from polluting the global namespace. But I think it's worth being more strict after all, so this commit adds 'static' to a lot more file-scope variables that aren't needed outside their own module.
2020-02-02 10:00:43 +00:00
static const char *display = NULL;
static enum {
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
PROMPT_UNSPEC, PROMPT_TTY, PROMPT_GUI
} prompt_type = PROMPT_UNSPEC;
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
static FingerprintType key_list_fptype = SSH_FPTYPE_DEFAULT;
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
static char *askpass_tty(const char *prompt)
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
{
New abstraction 'Seat', to pass to backends. This is a new vtable-based abstraction which is passed to a backend in place of Frontend, and it implements only the subset of the Frontend functions needed by a backend. (Many other Frontend functions still exist, notably the wide range of things called by terminal.c providing platform-independent operations on the GUI terminal window.) The purpose of making it a vtable is that this opens up the possibility of creating a backend as an internal implementation detail of some other activity, by providing just that one backend with a custom Seat that implements the methods differently. For example, this refactoring should make it feasible to directly implement an SSH proxy type, aka the 'jump host' feature supported by OpenSSH, aka 'open a secondary SSH session in MAINCHAN_DIRECT_TCP mode, and then expose the main channel of that as the Socket for the primary connection'. (Which of course you can already do by spawning 'plink -nc' as a separate proxy process, but this would permit it in the _same_ process without anything getting confused.) I've centralised a full set of stub methods in misc.c for the new abstraction, which allows me to get rid of several annoying stubs in the previous code. Also, while I'm here, I've moved a lot of duplicated modalfatalbox() type functions from application main program files into wincons.c / uxcons.c, which I think saves duplication overall. (A minor visible effect is that the prefixes on those console-based fatal error messages will now be more consistent between applications.)
2018-10-11 18:58:42 +00:00
prompts_t *p = new_prompts();
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
p->to_server = false;
Add a 'from_server' flag in prompts_t. This goes with the existing 'to_server' flag (indicating whether the values typed by the user are going to be sent over the wire or remain local), to indicate whether the _text of the prompts_ has come over the wire or is originated locally. Like to_server, nothing yet uses this. It's a hedge against the possibility of maybe having an option for all the auth prompts to work via GUI dialog boxes.
2019-03-09 15:50:23 +00:00
p->from_server = false;
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
p->name = dupstr("Pageant passphrase prompt");
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
add_prompt(p, dupcat(prompt, ": "), false);
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
SeatPromptResult spr = console_get_userpass_input(p);
assert(spr.kind != SPRK_INCOMPLETE);
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
if (spr.kind == SPRK_USER_ABORT) {
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
free_prompts(p);
return NULL;
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
} else if (spr.kind == SPRK_SW_ABORT) {
free_prompts(p);
char *err = spr_get_error_message(spr);
fprintf(stderr, "pageant: unable to read passphrase: %s", err);
sfree(err);
return NULL;
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
} else {
Use strbuf to store results in prompts_t. UBsan pointed out another memcpy from NULL (again with length 0) in the prompts_t system. When I looked at it, I realised that firstly prompt_ensure_result_size was an early not-so-good implementation of sgrowarray_nm that would benefit from being replaced with a call to the real one, and secondly, the whole system for storing prompt results should really have been replaced with strbufs with the no-move option, because that's doing all the same jobs better. So, now each prompt_t holds a strbuf in place of its previous manually managed string. prompt_ensure_result_size is gone (the console prompt-reading functions use strbuf_append, and everything else just adds to the strbuf in the usual marshal.c way). New functions exist to retrieve a prompt_t's result, either by reference or copied.
2020-01-21 20:19:47 +00:00
char *passphrase = prompt_get_result(p->prompts[0]);
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
free_prompts(p);
return passphrase;
}
}
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
static char *askpass_gui(const char *prompt)
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
{
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
char *passphrase;
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 success;
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
passphrase = gtk_askpass_main(
display, "Pageant passphrase prompt", prompt, &success);
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
if (!success) {
/* return value is error message */
fprintf(stderr, "%s\n", passphrase);
sfree(passphrase);
passphrase = NULL;
}
return passphrase;
}
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
static char *askpass(const char *prompt)
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
{
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
if (prompt_type == PROMPT_TTY) {
if (!have_controlling_tty()) {
fprintf(stderr, "no controlling terminal available "
"for passphrase prompt\n");
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
return NULL;
}
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
return askpass_tty(prompt);
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
}
if (prompt_type == PROMPT_GUI) {
if (!display) {
fprintf(stderr, "no graphical display available "
"for passphrase prompt\n");
return NULL;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
}
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
return askpass_gui(prompt);
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
}
if (have_controlling_tty()) {
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
return askpass_tty(prompt);
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
} else if (display) {
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
return askpass_gui(prompt);
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
} else {
fprintf(stderr, "no way to read a passphrase without tty or "
"X display\n");
return NULL;
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
}
}
Unix Pageant: -E option to load key files encrypted. This applies to both server modes ('pageant -E key.ppk [lifetime]') and client mode ('pageant -a -E key.ppk'). I'm not completely confident that the CLI syntax is actually right yet, but for the moment, it's enough that it _exists_. Now I don't have to test the encrypted-key loading via manually mocked-up agent requests.
2020-02-08 17:28:46 +00:00
static bool unix_add_keyfile(const char *filename_str, bool add_encrypted)
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
{
Filename *filename = filename_from_str(filename_str);
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
int status;
bool ret;
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
char *err;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
ret = true;
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
/*
* Try without a passphrase.
*/
Unix Pageant: -E option to load key files encrypted. This applies to both server modes ('pageant -E key.ppk [lifetime]') and client mode ('pageant -a -E key.ppk'). I'm not completely confident that the CLI syntax is actually right yet, but for the moment, it's enough that it _exists_. Now I don't have to test the encrypted-key loading via manually mocked-up agent requests.
2020-02-08 17:28:46 +00:00
status = pageant_add_keyfile(filename, NULL, &err, add_encrypted);
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
if (status == PAGEANT_ACTION_OK) {
goto cleanup;
} else if (status == PAGEANT_ACTION_FAILURE) {
fprintf(stderr, "pageant: %s: %s\n", filename_str, err);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
ret = false;
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
goto cleanup;
}
/*
* And now try prompting for a passphrase.
*/
while (1) {
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
char *prompt = dupprintf(
"Enter passphrase to load key '%s'", err);
char *passphrase = askpass(prompt);
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
sfree(err);
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
sfree(prompt);
Unix Pageant: fix a double-free when adding keys. I had freed the comment string coming back from pageant_add_keyfile, but not NULLed out the pointer, so that the cleanup code at the end of the function would have freed it again.
2015-05-13 12:22:44 +00:00
err = NULL;
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
if (!passphrase)
break;
Unix Pageant: -E option to load key files encrypted. This applies to both server modes ('pageant -E key.ppk [lifetime]') and client mode ('pageant -a -E key.ppk'). I'm not completely confident that the CLI syntax is actually right yet, but for the moment, it's enough that it _exists_. Now I don't have to test the encrypted-key loading via manually mocked-up agent requests.
2020-02-08 17:28:46 +00:00
status = pageant_add_keyfile(filename, passphrase, &err,
add_encrypted);
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
smemclr(passphrase, strlen(passphrase));
sfree(passphrase);
passphrase = NULL;
if (status == PAGEANT_ACTION_OK) {
goto cleanup;
} else if (status == PAGEANT_ACTION_FAILURE) {
fprintf(stderr, "pageant: %s: %s\n", filename_str, err);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
ret = false;
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
goto cleanup;
}
}
cleanup:
sfree(err);
filename_free(filename);
return ret;
}
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
void key_list_callback(void *ctx, char **fingerprints, const char *comment,
pageant -l: indicate whether keys are encrypted. The callback function to pageant_enum_keys now takes a flags parameter, which receives the flags word from the extended key list request, if available. (If not, then the flags word is passed as zero.) The only callback that uses this parameter is the one for printing text output from 'pageant -l', which uses it to print a suffix on each line, indicating whether the key is stored encrypted only (so it will need a passphrase on next use), or whether it's stored both encrypted _and_ unencrypted (so that 'pageant -R' will be able to return it to the former state).
2020-12-15 14:07:29 +00:00
uint32_t ext_flags, struct pageant_pubkey *key)
Unix Pageant: first draft of -l key list option. It doesn't look very pretty at the moment, but it lists the keys and gets the fingerprints right.
2015-05-11 17:34:45 +00:00
{
pageant -l: indicate whether keys are encrypted. The callback function to pageant_enum_keys now takes a flags parameter, which receives the flags word from the extended key list request, if available. (If not, then the flags word is passed as zero.) The only callback that uses this parameter is the one for printing text output from 'pageant -l', which uses it to print a suffix on each line, indicating whether the key is stored encrypted only (so it will need a passphrase on next use), or whether it's stored both encrypted _and_ unencrypted (so that 'pageant -R' will be able to return it to the former state).
2020-12-15 14:07:29 +00:00
const char *mode = "";
if (ext_flags & LIST_EXTENDED_FLAG_HAS_NO_CLEARTEXT_KEY)
mode = " (encrypted)";
else if (ext_flags & LIST_EXTENDED_FLAG_HAS_ENCRYPTED_KEY_FILE)
mode = " (re-encryptable)";
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
FingerprintType this_type =
ssh2_pick_fingerprint(fingerprints, key_list_fptype);
printf("%s %s%s\n", fingerprints[this_type], comment, mode);
Unix Pageant: first draft of -l key list option. It doesn't look very pretty at the moment, but it lists the keys and gets the fingerprints right.
2015-05-11 17:34:45 +00:00
}
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
struct key_find_ctx {
const char *string;
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 match_fp, match_comment;
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
bool match_fptypes[SSH_N_FPTYPES];
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
struct pageant_pubkey *found;
int nfound;
};
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
static bool match_fingerprint_string(
const char *string_orig, char **fingerprints,
const struct key_find_ctx *ctx)
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
{
const char *hash;
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
for (unsigned fptype = 0; fptype < SSH_N_FPTYPES; fptype++) {
if (!ctx->match_fptypes[fptype])
continue;
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
const char *fingerprint = fingerprints[fptype];
if (!fingerprint)
continue;
/* Find the hash in the fingerprint string. It'll be the word
* at the end. */
hash = strrchr(fingerprint, ' ');
assert(hash);
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
hash++;
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
const char *string = string_orig;
bool case_sensitive;
const char *ignore_chars = "";
switch (fptype) {
case SSH_FPTYPE_MD5:
Certificate-aware handling of key fingerprints. OpenSSH, when called on to give the fingerprint of a certified public key, will in many circumstances generate the hash of the public blob of the _underlying_ key, rather than the hash of the full certificate. I think the hash of the certificate is also potentially useful (if nothing else, it provides a way to tell apart multiple certificates on the same key). But I can also see that it's useful to be able to recognise a key as the same one 'really' (since all certificates on the same key share a private key, so they're unavoidably related). So I've dealt with this by introducing an extra pair of fingerprint types, giving the cross product of {MD5, SHA-256} x {base key only, full certificate}. You can manually select which one you want to see in some circumstances (notably PuTTYgen), and in others (such as diagnostics) both fingerprints will be emitted side by side via the new functions ssh2_double_fingerprint[_blob]. The default, following OpenSSH, is to just fingerprint the base key.
2022-08-05 17:08:59 +00:00
case SSH_FPTYPE_MD5_CERT:
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
/* MD5 fingerprints are in hex, so disregard case differences. */
case_sensitive = false;
/* And we don't really need to force the user to type the
* colons in between the digits, which are always the
* same. */
ignore_chars = ":";
break;
case SSH_FPTYPE_SHA256:
Certificate-aware handling of key fingerprints. OpenSSH, when called on to give the fingerprint of a certified public key, will in many circumstances generate the hash of the public blob of the _underlying_ key, rather than the hash of the full certificate. I think the hash of the certificate is also potentially useful (if nothing else, it provides a way to tell apart multiple certificates on the same key). But I can also see that it's useful to be able to recognise a key as the same one 'really' (since all certificates on the same key share a private key, so they're unavoidably related). So I've dealt with this by introducing an extra pair of fingerprint types, giving the cross product of {MD5, SHA-256} x {base key only, full certificate}. You can manually select which one you want to see in some circumstances (notably PuTTYgen), and in others (such as diagnostics) both fingerprints will be emitted side by side via the new functions ssh2_double_fingerprint[_blob]. The default, following OpenSSH, is to just fingerprint the base key.
2022-08-05 17:08:59 +00:00
case SSH_FPTYPE_SHA256_CERT:
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
/* Skip over the "SHA256:" prefix, which we don't really
* want to force the user to type. On the other hand,
* tolerate it on the input string. */
assert(strstartswith(hash, "SHA256:"));
hash += 7;
if (strstartswith(string, "SHA256:"))
string += 7;
/* SHA256 fingerprints are base64, which is intrinsically
* case sensitive. */
case_sensitive = true;
break;
}
/* Now see if the search string is a prefix of the full hash,
* neglecting colons and (where appropriate) case differences. */
while (1) {
string += strspn(string, ignore_chars);
hash += strspn(hash, ignore_chars);
if (!*string)
return true;
char sc = *string, hc = *hash;
if (!case_sensitive) {
sc = tolower((unsigned char)sc);
hc = tolower((unsigned char)hc);
}
if (sc != hc)
break;
string++;
hash++;
}
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
}
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
return false;
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
}
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
void key_find_callback(void *vctx, char **fingerprints,
pageant -l: indicate whether keys are encrypted. The callback function to pageant_enum_keys now takes a flags parameter, which receives the flags word from the extended key list request, if available. (If not, then the flags word is passed as zero.) The only callback that uses this parameter is the one for printing text output from 'pageant -l', which uses it to print a suffix on each line, indicating whether the key is stored encrypted only (so it will need a passphrase on next use), or whether it's stored both encrypted _and_ unencrypted (so that 'pageant -R' will be able to return it to the former state).
2020-12-15 14:07:29 +00:00
const char *comment, uint32_t ext_flags,
struct pageant_pubkey *key)
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
{
struct key_find_ctx *ctx = (struct key_find_ctx *)vctx;
if ((ctx->match_comment && !strcmp(ctx->string, comment)) ||
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
(ctx->match_fp && match_fingerprint_string(ctx->string, fingerprints,
Formatting: normalise to { on same line. There were remarkably few of these, but I spotted one while preparing the previous commit, and then found a handful more.
2022-12-28 15:37:57 +00:00
ctx))) {
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
if (!ctx->found)
ctx->found = pageant_pubkey_copy(key);
ctx->nfound++;
}
}
struct pageant_pubkey *find_key(const char *string, char **retstr)
{
Refactor 'struct context *ctx = &actx' pattern. When I'm declaring a local instance of some context structure type to pass to a function which will pass it in turn to a callback, I've tended to use a declaration of the form struct context actx, *ctx = &actx; so that the outermost caller can initialise the context, and/or read out fields of it afterwards, by the same syntax 'ctx->foo' that the callback function will be using. So you get visual consistency between the two functions that share this context. It only just occurred to me that there's a much neater way to declare a context struct of this kind, which still makes 'ctx' behave like a pointer in the owning function, and doesn't need all that weird verbiage or a spare variable name: struct context ctx[1]; That's much nicer! I've switched to doing that in all existing cases I could find, and also in a couple of cases where I hadn't previously bothered to do the previous more cumbersome idiom.
2019-12-22 08:15:52 +00:00
struct key_find_ctx ctx[1];
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
struct pageant_pubkey key_in, *key_ret;
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 try_file = true, try_fp = true, try_comment = true;
bool file_errors = false;
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
bool try_all_fptypes = true;
FingerprintType fptype = SSH_FPTYPE_DEFAULT;
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
/*
* Trim off disambiguating prefixes telling us how to interpret
* the provided string.
*/
if (!strncmp(string, "file:", 5)) {
string += 5;
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
try_fp = false;
try_comment = false;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
file_errors = true; /* also report failure to load the file */
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
} else if (!strncmp(string, "comment:", 8)) {
string += 8;
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
try_file = false;
try_fp = false;
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
} else if (!strncmp(string, "fp:", 3)) {
string += 3;
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
try_file = false;
try_comment = false;
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
} else if (!strncmp(string, "fingerprint:", 12)) {
string += 12;
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
try_file = false;
try_comment = false;
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
} else if (!strnicmp(string, "md5:", 4)) {
string += 4;
try_file = false;
try_comment = false;
try_all_fptypes = false;
fptype = SSH_FPTYPE_MD5;
} else if (!strncmp(string, "sha256:", 7)) {
string += 7;
try_file = false;
try_comment = false;
try_all_fptypes = false;
fptype = SSH_FPTYPE_SHA256;
Certificate-aware handling of key fingerprints. OpenSSH, when called on to give the fingerprint of a certified public key, will in many circumstances generate the hash of the public blob of the _underlying_ key, rather than the hash of the full certificate. I think the hash of the certificate is also potentially useful (if nothing else, it provides a way to tell apart multiple certificates on the same key). But I can also see that it's useful to be able to recognise a key as the same one 'really' (since all certificates on the same key share a private key, so they're unavoidably related). So I've dealt with this by introducing an extra pair of fingerprint types, giving the cross product of {MD5, SHA-256} x {base key only, full certificate}. You can manually select which one you want to see in some circumstances (notably PuTTYgen), and in others (such as diagnostics) both fingerprints will be emitted side by side via the new functions ssh2_double_fingerprint[_blob]. The default, following OpenSSH, is to just fingerprint the base key.
2022-08-05 17:08:59 +00:00
} else if (!strnicmp(string, "md5-cert:", 9)) {
string += 9;
try_file = false;
try_comment = false;
try_all_fptypes = false;
fptype = SSH_FPTYPE_MD5_CERT;
} else if (!strncmp(string, "sha256-cert:", 12)) {
string += 12;
try_file = false;
try_comment = false;
try_all_fptypes = false;
fptype = SSH_FPTYPE_SHA256_CERT;
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
}
/*
* Try interpreting the string as a key file name.
*/
if (try_file) {
Filename *fn = filename_from_str(string);
int keytype = key_type(fn);
if (keytype == SSH_KEYTYPE_SSH1 ||
keytype == SSH_KEYTYPE_SSH1_PUBLIC) {
const char *error;
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 09:59:39 +00:00
key_in.blob = strbuf_new();
Rename all public/private key load/save functions. Now they have names that are more consistent (no more userkey_this but that_userkey); a bit shorter; and, most importantly, all the current functions end in _f to indicate that they deal with keys stored in disk files. I'm about to add a second set of entry points that deal with keys via the more general BinarySource / BinarySink interface, which will sit alongside these with a different suffix.
2020-01-05 10:28:45 +00:00
if (!rsa1_loadpub_f(fn, BinarySink_UPCAST(key_in.blob),
NULL, &error)) {
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 09:59:39 +00:00
strbuf_free(key_in.blob);
key_in.blob = NULL;
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
if (file_errors) {
*retstr = dupprintf("unable to load file '%s': %s",
string, error);
filename_free(fn);
return NULL;
}
uxpgnt: correct control flow in find_key(). If we try to interpret a string argument as the name of a key file, sometimes we it's in circumstances where we _know_ it's a key file, so we must print an error message and return failure if the file can't be loaded. Other times it's not, and we just fall back to interpreting the argument in some other way (e.g. as a pattern match against the comment or fingerprint of a key already in the agent). My code dealing with failure returns from the public-key loading functions were mishandling the latter case, if they identified a file as existing and looking more or less like some kind of key file but then it turned out to have a format error; they would try to copy and return a public key that they didn't actually have. Even if pageant_pubkey_copy avoided crashing as a result, this would still inhibit the fallback to treating the input string as some other kind of pattern match.
2017-02-15 05:31:30 +00:00
} else {
/*
* If we've successfully loaded the file, stop here - we
* already have a key blob and need not go to the agent to
* list things.
*/
key_in.ssh_version = 1;
key_in.comment = NULL;
key_ret = pageant_pubkey_copy(&key_in);
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 09:59:39 +00:00
strbuf_free(key_in.blob);
key_in.blob = NULL;
uxpgnt: correct control flow in find_key(). If we try to interpret a string argument as the name of a key file, sometimes we it's in circumstances where we _know_ it's a key file, so we must print an error message and return failure if the file can't be loaded. Other times it's not, and we just fall back to interpreting the argument in some other way (e.g. as a pattern match against the comment or fingerprint of a key already in the agent). My code dealing with failure returns from the public-key loading functions were mishandling the latter case, if they identified a file as existing and looking more or less like some kind of key file but then it turned out to have a format error; they would try to copy and return a public key that they didn't actually have. Even if pageant_pubkey_copy avoided crashing as a result, this would still inhibit the fallback to treating the input string as some other kind of pattern match.
2017-02-15 05:31:30 +00:00
filename_free(fn);
return key_ret;
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
}
} else if (keytype == SSH_KEYTYPE_SSH2 ||
keytype == SSH_KEYTYPE_SSH2_PUBLIC_RFC4716 ||
keytype == SSH_KEYTYPE_SSH2_PUBLIC_OPENSSH) {
const char *error;
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 09:59:39 +00:00
key_in.blob = strbuf_new();
Rename all public/private key load/save functions. Now they have names that are more consistent (no more userkey_this but that_userkey); a bit shorter; and, most importantly, all the current functions end in _f to indicate that they deal with keys stored in disk files. I'm about to add a second set of entry points that deal with keys via the more general BinarySource / BinarySink interface, which will sit alongside these with a different suffix.
2020-01-05 10:28:45 +00:00
if (!ppk_loadpub_f(fn, NULL, BinarySink_UPCAST(key_in.blob),
NULL, &error)) {
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 09:59:39 +00:00
strbuf_free(key_in.blob);
key_in.blob = NULL;
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
if (file_errors) {
*retstr = dupprintf("unable to load file '%s': %s",
string, error);
filename_free(fn);
return NULL;
}
uxpgnt: correct control flow in find_key(). If we try to interpret a string argument as the name of a key file, sometimes we it's in circumstances where we _know_ it's a key file, so we must print an error message and return failure if the file can't be loaded. Other times it's not, and we just fall back to interpreting the argument in some other way (e.g. as a pattern match against the comment or fingerprint of a key already in the agent). My code dealing with failure returns from the public-key loading functions were mishandling the latter case, if they identified a file as existing and looking more or less like some kind of key file but then it turned out to have a format error; they would try to copy and return a public key that they didn't actually have. Even if pageant_pubkey_copy avoided crashing as a result, this would still inhibit the fallback to treating the input string as some other kind of pattern match.
2017-02-15 05:31:30 +00:00
} else {
/*
* If we've successfully loaded the file, stop here - we
* already have a key blob and need not go to the agent to
* list things.
*/
key_in.ssh_version = 2;
key_in.comment = NULL;
key_ret = pageant_pubkey_copy(&key_in);
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 09:59:39 +00:00
strbuf_free(key_in.blob);
key_in.blob = NULL;
uxpgnt: correct control flow in find_key(). If we try to interpret a string argument as the name of a key file, sometimes we it's in circumstances where we _know_ it's a key file, so we must print an error message and return failure if the file can't be loaded. Other times it's not, and we just fall back to interpreting the argument in some other way (e.g. as a pattern match against the comment or fingerprint of a key already in the agent). My code dealing with failure returns from the public-key loading functions were mishandling the latter case, if they identified a file as existing and looking more or less like some kind of key file but then it turned out to have a format error; they would try to copy and return a public key that they didn't actually have. Even if pageant_pubkey_copy avoided crashing as a result, this would still inhibit the fallback to treating the input string as some other kind of pattern match.
2017-02-15 05:31:30 +00:00
filename_free(fn);
return key_ret;
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
}
} else {
if (file_errors) {
*retstr = dupprintf("unable to load key file '%s': %s",
string, key_type_to_str(keytype));
filename_free(fn);
return NULL;
}
}
filename_free(fn);
}
/*
* Failing that, go through the keys in the agent, and match
* against fingerprints and comments as appropriate.
*/
ctx->string = string;
ctx->match_fp = try_fp;
ctx->match_comment = try_comment;
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
for (unsigned i = 0; i < SSH_N_FPTYPES; i++)
ctx->match_fptypes[i] = (try_all_fptypes || i == fptype);
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
ctx->found = NULL;
ctx->nfound = 0;
if (pageant_enum_keys(key_find_callback, ctx, retstr) ==
PAGEANT_ACTION_FAILURE)
return NULL;
if (ctx->nfound == 0) {
*retstr = dupstr("no key matched");
assert(!ctx->found);
return NULL;
} else if (ctx->nfound > 1) {
*retstr = dupstr("multiple keys matched");
assert(ctx->found);
pageant_pubkey_free(ctx->found);
return NULL;
}
assert(ctx->found);
return ctx->found;
}
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
void run_client(void)
{
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
const struct cmdline_key_action *act;
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
struct pageant_pubkey *key;
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 errors = false;
Unix Pageant: first draft of -l key list option. It doesn't look very pretty at the moment, but it lists the keys and gets the fingerprints right.
2015-05-11 17:34:45 +00:00
char *retstr;
Unix Pageant: --test-sign client option. This reads data from standard input, turns it into an SSH-2 sign request, and writes the resulting signature blob to standard output. I don't really anticipate many uses for this other than testing. But it _is_ convenient for testing changes to Pageant itself: it lets me ask for a signature without first having to construct a pointless SSH session that will accept the relevant key.
2020-02-09 21:56:21 +00:00
LoadedFile *message = lf_new(AGENT_MAX_MSGLEN);
bool message_loaded = false, message_ok = false;
strbuf *signature = strbuf_new();
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
Unix Pageant: link in uxagentc.c and uxcons.c. This brings in the code we'll need to request passphrases from the terminal, and to talk to an existing SSH agent as a client. Adding uxcons.c required adjusting the set of stub functions in uxpgnt.c: uxcons.c removed the need for several, but added one of its own (log_eventlog). A net win, though.
2015-05-11 16:56:51 +00:00
if (!agent_exists()) {
fprintf(stderr, "pageant: no agent running to talk to\n");
exit(1);
}
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
for (act = keyact_head; act; act = act->next) {
switch (act->action) {
case KEYACT_CLIENT_ADD:
Unix Pageant: -E option to load key files encrypted. This applies to both server modes ('pageant -E key.ppk [lifetime]') and client mode ('pageant -a -E key.ppk'). I'm not completely confident that the CLI syntax is actually right yet, but for the moment, it's enough that it _exists_. Now I don't have to test the encrypted-key loading via manually mocked-up agent requests.
2020-02-08 17:28:46 +00:00
case KEYACT_CLIENT_ADD_ENCRYPTED:
if (!unix_add_keyfile(act->filename,
act->action == KEYACT_CLIENT_ADD_ENCRYPTED))
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
errors = true;
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
break;
Unix Pageant: first draft of -l key list option. It doesn't look very pretty at the moment, but it lists the keys and gets the fingerprints right.
2015-05-11 17:34:45 +00:00
case KEYACT_CLIENT_LIST:
if (pageant_enum_keys(key_list_callback, NULL, &retstr) ==
PAGEANT_ACTION_FAILURE) {
fprintf(stderr, "pageant: listing keys: %s\n", retstr);
sfree(retstr);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
errors = true;
Unix Pageant: first draft of -l key list option. It doesn't look very pretty at the moment, but it lists the keys and gets the fingerprints right.
2015-05-11 17:34:45 +00:00
}
break;
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
case KEYACT_CLIENT_DEL:
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
key = NULL;
if (!(key = find_key(act->filename, &retstr)) ||
pageant_delete_key(key, &retstr) == PAGEANT_ACTION_FAILURE) {
fprintf(stderr, "pageant: deleting key '%s': %s\n",
act->filename, retstr);
sfree(retstr);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
errors = true;
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
}
if (key)
pageant_pubkey_free(key);
break;
Unix Pageant: support -r and -R options to re-encrypt. This links up the new re-encryption facilities to the Unix Pageant client-mode command line. Analogously to -d and -D, 'pageant -r key-id' re-encrypts a single key, and 'pageant -R' re-encrypts everything.
2020-02-15 16:40:19 +00:00
case KEYACT_CLIENT_REENCRYPT:
key = NULL;
if (!(key = find_key(act->filename, &retstr)) ||
pageant_reencrypt_key(key, &retstr) == PAGEANT_ACTION_FAILURE) {
fprintf(stderr, "pageant: re-encrypting key '%s': %s\n",
act->filename, retstr);
sfree(retstr);
errors = true;
}
if (key)
pageant_pubkey_free(key);
break;
Unix Pageant: provide public-key extraction options. I've decided against implementing an option exactly analogous to 'ssh-add -L' (printing the full public key of everything in the agent). Instead, you can identify a specific key to display in full, by any of the same means -d lets you use, and then print it in either of the public key formats we support.
2015-05-12 13:48:32 +00:00
case KEYACT_CLIENT_PUBLIC_OPENSSH:
case KEYACT_CLIENT_PUBLIC:
key = NULL;
if (!(key = find_key(act->filename, &retstr))) {
fprintf(stderr, "pageant: finding key '%s': %s\n",
act->filename, retstr);
sfree(retstr);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
errors = true;
Unix Pageant: provide public-key extraction options. I've decided against implementing an option exactly analogous to 'ssh-add -L' (printing the full public key of everything in the agent). Instead, you can identify a specific key to display in full, by any of the same means -d lets you use, and then print it in either of the public key formats we support.
2015-05-12 13:48:32 +00:00
} else {
FILE *fp = stdout; /* FIXME: add a -o option? */
if (key->ssh_version == 1) {
Remove obsolete functions. There are several old functions that the previous commits have removed all, or nearly all, of the references to. match_ssh_id is superseded by ptrlen_eq_string; get_ssh_{string,uint32} is yet another replicated set of decode functions (this time _partly_ centralised into misc.c); the old APIs for the SSH-1 RSA decode functions are gone (together with their last couple of holdout clients), as are ssh{1,2}_{read,write}_bignum and ssh{1,2}_bignum_length. Particularly odd was the use of ssh1_{read,write}_bignum in the SSH-2 Diffie-Hellman implementation. I'd completely forgotten I did that! Now replaced with a raw bignum_from_bytes, which is simpler anyway.
2018-05-29 19:36:21 +00:00
BinarySource src[1];
Remove a lot of pointless 'struct' keywords. This is the commit that f3295e0fb _should_ have been. Yesterday I just added some typedefs so that I didn't have to wear out my fingers typing 'struct' in new code, but what I ought to have done is to move all the typedefs into defs.h with the rest, and then go through cleaning up the legacy 'struct's all through the existing code. But I was mostly trying to concentrate on getting the test suite finished, so I just did the minimum. Now it's time to come back and do it better.
2019-01-04 06:51:44 +00:00
RSAKey rkey;
Remove obsolete functions. There are several old functions that the previous commits have removed all, or nearly all, of the references to. match_ssh_id is superseded by ptrlen_eq_string; get_ssh_{string,uint32} is yet another replicated set of decode functions (this time _partly_ centralised into misc.c); the old APIs for the SSH-1 RSA decode functions are gone (together with their last couple of holdout clients), as are ssh{1,2}_{read,write}_bignum and ssh{1,2}_bignum_length. Particularly odd was the use of ssh1_{read,write}_bignum in the SSH-2 Diffie-Hellman implementation. I'd completely forgotten I did that! Now replaced with a raw bignum_from_bytes, which is simpler anyway.
2018-05-29 19:36:21 +00:00
BinarySource_BARE_INIT(src, key->blob->u, key->blob->len);
Unix Pageant: provide public-key extraction options. I've decided against implementing an option exactly analogous to 'ssh-add -L' (printing the full public key of everything in the agent). Instead, you can identify a specific key to display in full, by any of the same means -d lets you use, and then print it in either of the public key formats we support.
2015-05-12 13:48:32 +00:00
memset(&rkey, 0, sizeof(rkey));
rkey.comment = dupstr(key->comment);
Remove 'keystr' parameter in get_rsa_ssh1_pub. This parameter returned a substring of the input, which was used for two purposes. Firstly, it was used to hash the host and server keys during the initial SSH-1 key setup phase; secondly, it was used to check the keys in Pageant against the public key blob of a key specified on the command line. Unfortunately, those two purposes didn't agree! The first one needs just the bare key modulus bytes (without even the SSH-1 mpint length header); the second needs the entire key blob. So, actually, it seems to have never worked in SSH-1 to say 'putty -i keyfile' and have PuTTY find that key in Pageant and not have to ask for the passphrase to decrypt the version on disk. Fixed by removing that parameter completely, which simplifies all the _other_ call sites, and replacing it by custom code in those two places that each does the actually right thing.
2018-06-03 07:23:07 +00:00
get_rsa_ssh1_pub(src, &rkey, RSA_SSH1_EXPONENT_FIRST);
Unix Pageant: provide public-key extraction options. I've decided against implementing an option exactly analogous to 'ssh-add -L' (printing the full public key of everything in the agent). Instead, you can identify a specific key to display in full, by any of the same means -d lets you use, and then print it in either of the public key formats we support.
2015-05-12 13:48:32 +00:00
ssh1_write_pubkey(fp, &rkey);
freersakey(&rkey);
} else {
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 09:59:39 +00:00
ssh2_write_pubkey(fp, key->comment,
key->blob->u,
key->blob->len,
Unix Pageant: provide public-key extraction options. I've decided against implementing an option exactly analogous to 'ssh-add -L' (printing the full public key of everything in the agent). Instead, you can identify a specific key to display in full, by any of the same means -d lets you use, and then print it in either of the public key formats we support.
2015-05-12 13:48:32 +00:00
(act->action == KEYACT_CLIENT_PUBLIC ?
SSH_KEYTYPE_SSH2_PUBLIC_RFC4716 :
SSH_KEYTYPE_SSH2_PUBLIC_OPENSSH));
}
pageant_pubkey_free(key);
}
break;
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
case KEYACT_CLIENT_DEL_ALL:
Unix Pageant: support -D, to delete all keys.
2015-05-12 13:55:44 +00:00
if (pageant_delete_all_keys(&retstr) == PAGEANT_ACTION_FAILURE) {
fprintf(stderr, "pageant: deleting all keys: %s\n", retstr);
sfree(retstr);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
errors = true;
Unix Pageant: support -D, to delete all keys.
2015-05-12 13:55:44 +00:00
}
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
break;
Unix Pageant: support -r and -R options to re-encrypt. This links up the new re-encryption facilities to the Unix Pageant client-mode command line. Analogously to -d and -D, 'pageant -r key-id' re-encrypts a single key, and 'pageant -R' re-encrypts everything.
2020-02-15 16:40:19 +00:00
case KEYACT_CLIENT_REENCRYPT_ALL: {
int status = pageant_reencrypt_all_keys(&retstr);
if (status == PAGEANT_ACTION_FAILURE) {
fprintf(stderr, "pageant: re-encrypting all keys: "
"%s\n", retstr);
sfree(retstr);
errors = true;
} else if (status == PAGEANT_ACTION_WARNING) {
fprintf(stderr, "pageant: re-encrypting all keys: "
"warning: %s\n", retstr);
sfree(retstr);
}
break;
}
Unix Pageant: --test-sign client option. This reads data from standard input, turns it into an SSH-2 sign request, and writes the resulting signature blob to standard output. I don't really anticipate many uses for this other than testing. But it _is_ convenient for testing changes to Pageant itself: it lets me ask for a signature without first having to construct a pointless SSH session that will accept the relevant key.
2020-02-09 21:56:21 +00:00
case KEYACT_CLIENT_SIGN:
key = NULL;
if (!message_loaded) {
message_loaded = true;
switch(lf_load_fp(message, stdin)) {
case LF_TOO_BIG:
fprintf(stderr, "pageant: message to sign is too big\n");
errors = true;
break;
case LF_ERROR:
fprintf(stderr, "pageant: reading message to sign: %s\n",
strerror(errno));
errors = true;
break;
case LF_OK:
message_ok = true;
break;
}
}
if (!message_ok)
break;
strbuf_clear(signature);
if (!(key = find_key(act->filename, &retstr)) ||
pageant_sign(key, ptrlen_from_lf(message), signature,
sign_flags, &retstr) == PAGEANT_ACTION_FAILURE) {
fprintf(stderr, "pageant: signing with key '%s': %s\n",
act->filename, retstr);
sfree(retstr);
errors = true;
} else {
fwrite(signature->s, 1, signature->len, stdout);
}
if (key)
pageant_pubkey_free(key);
break;
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
default:
Replace assert(false) with an unreachable() macro. Taking a leaf out of the LLVM code base: this macro still includes an assert(false) so that the message will show up in a typical build, but it follows it up with a call to a function explicitly marked as no- return. So this ought to do a better job of convincing compilers that once a code path hits this function it _really doesn't_ have to still faff about with making up a bogus return value or filling in a variable that 'might be used uninitialised' in the following code that won't be reached anyway. I've gone through the existing code looking for the assert(false) / assert(0) idiom and replaced all the ones I found with the new macro, which also meant I could remove a few pointless return statements and variable initialisations that I'd already had to put in to placate compiler front ends.
2019-01-03 08:12:19 +00:00
unreachable("Invalid client action found");
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
}
}
Unix Pageant: --test-sign client option. This reads data from standard input, turns it into an SSH-2 sign request, and writes the resulting signature blob to standard output. I don't really anticipate many uses for this other than testing. But it _is_ convenient for testing changes to Pageant itself: it lets me ask for a signature without first having to construct a pointless SSH session that will accept the relevant key.
2020-02-09 21:56:21 +00:00
lf_free(message);
strbuf_free(signature);
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
if (errors)
exit(1);
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
}
Name vtable structure types more consistently. Now they're all called FooVtable, instead of a mixture of that and Foo_vtable.
2018-10-05 06:03:46 +00:00
static const PlugVtable X11Connection_plugvt = {
Centralise stub plug/socket functions. In the previous few commits I noticed some repeated work in the form of pointless empty implementations of Plug's log method, plus some existing (and some new) empty cases of Socket's endpoint_info. As a cleanup, I'm replacing as many as I can find with uses of a central null implementation in the stubs directory.
2024-06-29 11:07:59 +00:00
.log = nullplug_log,
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
.closing = x11_closing,
Centralise stub plug/socket functions. In the previous few commits I noticed some repeated work in the form of pointless empty implementations of Plug's log method, plus some existing (and some new) empty cases of Socket's endpoint_info. As a cleanup, I'm replacing as many as I can find with uses of a central null implementation in the stubs directory.
2024-06-29 11:07:59 +00:00
.receive = nullplug_receive,
.sent = nullplug_sent,
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
};
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
static bool agent_loop_pw_setup(void *vctx, pollwrapper *pw)
{
struct uxpgnt_client *upc = (struct uxpgnt_client *)vctx;
if (signalpipe[0] >= 0) {
pollwrap_add_fd_rwx(pw, signalpipe[0], SELECT_R);
}
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
if (upc->prompt_active)
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
pollwrap_add_fd_rwx(pw, upc->passphrase_fd, SELECT_R);
return true;
}
static void agent_loop_pw_check(void *vctx, pollwrapper *pw)
{
struct uxpgnt_client *upc = (struct uxpgnt_client *)vctx;
if (life == LIFE_TTY) {
/*
* Every time we wake up (whether it was due to tty_timer
* elapsing or for any other reason), poll to see if we still
* have a controlling terminal. If we don't, then our
* containing tty session has ended, so it's time to clean up
* and leave.
*/
if (!have_controlling_tty()) {
time_to_die = true;
return;
}
}
if (signalpipe[0] >= 0 &&
pollwrap_check_fd_rwx(pw, signalpipe[0], SELECT_R)) {
char c[1];
if (read(signalpipe[0], c, 1) <= 0)
/* ignore error */;
/* ignore its value; it'll be `x' */
while (1) {
int status;
pid_t pid;
pid = waitpid(-1, &status, WNOHANG);
if (pid <= 0)
break;
if (pid == upc->termination_pid)
time_to_die = true;
}
}
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
if (upc->prompt_active &&
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
pollwrap_check_fd_rwx(pw, upc->passphrase_fd, SELECT_R)) {
char c;
int retd = read(upc->passphrase_fd, &c, 1);
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
switch (upc->prompt_type) {
case RTPROMPT_GUI:
if (retd <= 0) {
close(upc->passphrase_fd);
upc->passphrase_fd = -1;
bool ok = (retd == 0);
if (!strbuf_chomp(upc->prompt_buf, '\n'))
ok = false;
passphrase_done(upc, ok);
} else {
put_byte(upc->prompt_buf, c);
}
break;
case RTPROMPT_DEBUG:
if (retd <= 0) {
passphrase_done(upc, false);
/* Now never try to read from stdin again */
upc->prompt_type = RTPROMPT_UNAVAILABLE;
break;
}
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
switch (c) {
case '\n':
case '\r':
passphrase_done(upc, true);
break;
case '\004':
passphrase_done(upc, false);
break;
case '\b':
case '\177':
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
strbuf_shrink_by(upc->prompt_buf, 1);
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
break;
case '\025':
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
strbuf_clear(upc->prompt_buf);
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
break;
default:
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
put_byte(upc->prompt_buf, c);
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
break;
}
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
break;
case RTPROMPT_UNAVAILABLE:
unreachable("Should never have started a prompt at all");
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
}
}
}
static bool agent_loop_continue(void *vctx, bool fd, bool cb)
{
return !time_to_die;
}
Unix Pageant: add a --symlink option. I've often found it useful that you can make symlinks to Unix-domain sockets, and then connect() on the symlink path will redirect to the original socket. This commit adds an option to Unix Pageant which will make it symlink its socket path to a link location of your choice. My initial use case is when running Pageant in debug mode during development: if you run a new copy of it every few minutes after making a code change, then it's annoying to have it change its socket path every time so you have to keep pasting its setup command into your test shell. Not any more! Now you can run 'pageant --debug --symlink fixed-location', and then your test shell can point its SSH_AUTH_SOCK at the fixed location all the time. There are very likely other use cases too, but that's the one that motivated me to add the option.
2020-02-02 18:52:10 +00:00
void run_agent(FILE *logfp, const char *symlink_path)
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
{
const char *err;
Factor out Unix Pageant's socket creation. The code in Pageant that sets up the Unix socket and its containing directory now lives in a separate file, uxagentsock.c, where it will also be callable from the upcoming new SSH server when it wants to create a similar socket for agent forwarding. While I'm at it, I've also added a feature to create a watchdog subprocess that will try to clean up the socket and directory once Pageant itself terminates, in the hope of leaving less cruft lying around /tmp.
2018-10-14 17:48:02 +00:00
char *errw;
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
struct pageant_listen_state *pl;
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Plug *pl_plug;
Socket *sock;
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 errors = false;
Clean up Unix Pageant's setup and teardown. I've moved the listening socket setup back to before the lifetime preparations, so in particular we find out that we couldn't bind to the socket _before_ we fork. The only part that really needed to come after lifetime setup was the logging setup, so that's now a separate function called later. Also, the random exit(0)s in silly places like x11_closing have turned into setting a time_to_die flag, so that all clean exits funnel back to the end of main() which at least tries to tidy up a bit afterwards. (Finally, fixed a small bug in testing the return value of waitpid(), which only showed up once we didn't exit(0) after the first wait. Ahem.)
2015-05-07 18:04:25 +00:00
Conf *conf;
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
const struct cmdline_key_action *act;
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
pageant_init();
/*
* Start by loading any keys provided on the command line.
*/
for (act = keyact_head; act; act = act->next) {
Unix Pageant: -E option to load key files encrypted. This applies to both server modes ('pageant -E key.ppk [lifetime]') and client mode ('pageant -a -E key.ppk'). I'm not completely confident that the CLI syntax is actually right yet, but for the moment, it's enough that it _exists_. Now I don't have to test the encrypted-key loading via manually mocked-up agent requests.
2020-02-08 17:28:46 +00:00
assert(act->action == KEYACT_AGENT_LOAD ||
act->action == KEYACT_AGENT_LOAD_ENCRYPTED);
if (!unix_add_keyfile(act->filename,
act->action == KEYACT_AGENT_LOAD_ENCRYPTED))
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
errors = true;
Unix Pageant: support loading keys. You can now load keys at Pageant init time, by putting the key file names as bare arguments on the command line, e.g. 'pageant -T key.ppk' or 'pageant key.ppk --exec some command'; also, 'pageant -a key.ppk' behaves more or less like ssh-add, contacting an existing agent to add the key. The askpass() function currently supports terminal-based prompting only. X11 askpass is yet to be implemented.
2015-05-11 16:58:55 +00:00
}
if (errors)
exit(1);
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
/*
* Set up a listening socket and run Pageant on it.
*/
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 uxpgnt_client upc[1];
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
memset(upc, 0, sizeof(upc));
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
upc->plc.vt = &uxpgnt_vtable;
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
upc->logfp = logfp;
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
upc->passphrase_fd = -1;
upc->termination_pid = -1;
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
upc->prompt_buf = strbuf_new_nm();
upc->prompt_type = display ? RTPROMPT_GUI : RTPROMPT_UNAVAILABLE;
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
pl = pageant_listener_new(&pl_plug, &upc->plc);
Factor out Unix Pageant's socket creation. The code in Pageant that sets up the Unix socket and its containing directory now lives in a separate file, uxagentsock.c, where it will also be callable from the upcoming new SSH server when it wants to create a similar socket for agent forwarding. While I'm at it, I've also added a feature to create a watchdog subprocess that will try to clean up the socket and directory once Pageant itself terminates, in the hope of leaving less cruft lying around /tmp.
2018-10-14 17:48:02 +00:00
sock = platform_make_agent_socket(pl_plug, PAGEANT_DIR_PREFIX,
&errw, &socketname);
if (!sock) {
fprintf(stderr, "pageant: %s\n", errw);
sfree(errw);
Clean up Unix Pageant's setup and teardown. I've moved the listening socket setup back to before the lifetime preparations, so in particular we find out that we couldn't bind to the socket _before_ we fork. The only part that really needed to come after lifetime setup was the logging setup, so that's now a separate function called later. Also, the random exit(0)s in silly places like x11_closing have turned into setting a time_to_die flag, so that all clean exits funnel back to the end of main() which at least tries to tidy up a bit afterwards. (Finally, fixed a small bug in testing the return value of waitpid(), which only showed up once we didn't exit(0) after the first wait. Ahem.)
2015-05-07 18:04:25 +00:00
exit(1);
}
pageant_listener_got_socket(pl, sock);
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
Unix Pageant: add a --symlink option. I've often found it useful that you can make symlinks to Unix-domain sockets, and then connect() on the symlink path will redirect to the original socket. This commit adds an option to Unix Pageant which will make it symlink its socket path to a link location of your choice. My initial use case is when running Pageant in debug mode during development: if you run a new copy of it every few minutes after making a code change, then it's annoying to have it change its socket path every time so you have to keep pasting its setup command into your test shell. Not any more! Now you can run 'pageant --debug --symlink fixed-location', and then your test shell can point its SSH_AUTH_SOCK at the fixed location all the time. There are very likely other use cases too, but that's the one that motivated me to add the option.
2020-02-02 18:52:10 +00:00
if (symlink_path) {
/*
* Try to make a symlink to the Unix socket, in a location of
* the user's choosing.
*
* If the link already exists, we want to replace it. There
* are two ways we could do this: either make it under another
* name and then rename it over the top, or remove the old
* link first. The former is what 'ln -sf' does, on the
* grounds that it's more atomic. But I think in this case,
* where the expected use case is that the previous agent has
* long since shut down, atomicity isn't a critical concern
* compared to not accidentally overwriting some non-symlink
* that might have important data in it!
*/
struct stat st;
if (lstat(symlink_path, &st) == 0 && S_ISLNK(st.st_mode))
unlink(symlink_path);
if (symlink(socketname, symlink_path) < 0)
fprintf(stderr, "pageant: making symlink %s: %s\n",
symlink_path, strerror(errno));
}
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
conf = conf_new();
conf_set_int(conf, CONF_proxy_type, PROXY_NONE);
/*
* Lifetime preparations.
*/
if (life == LIFE_X11) {
struct X11Display *disp;
void *greeting;
int greetinglen;
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Socket *s;
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
struct X11Connection *conn;
Return an error message from x11_setup_display. The lack of one of those has been a long-standing FIXME for ages.
2018-10-06 09:43:04 +00:00
char *x11_setup_err;
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
if (!display) {
fprintf(stderr, "pageant: no DISPLAY for -X mode\n");
exit(1);
}
Return an error message from x11_setup_display. The lack of one of those has been a long-standing FIXME for ages.
2018-10-06 09:43:04 +00:00
disp = x11_setup_display(display, conf, &x11_setup_err);
if (!disp) {
fprintf(stderr, "pageant: unable to connect to X server: %s\n",
x11_setup_err);
sfree(x11_setup_err);
exit(1);
}
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
conn = snew(struct X11Connection);
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
conn->plug.vt = &X11Connection_plugvt;
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
s = new_connection(sk_addr_dup(disp->addr),
disp->realhost, disp->port,
sshproxy: share the caller's LogPolicy. Now new_connection() takes an optional LogPolicy * argument, and passes it on to the SshProxy setup. This means that SshProxy's implementation of the LogPolicy trait can answer queries like askappend() and logging_error() by passing them on to the same LogPolicy used by the main backend. Not all callers of new_connection have a LogPolicy, so we still have to fall back to the previous conservative default behaviour if SshProxy doesn't have a LogPolicy it can ask. The main backend implementations didn't _quite_ have access to a LogPolicy already, but they do have a LogContext, which has a LogPolicy vtable pointer inside it; so I've added a query function log_get_policy() which allows them to extract that pointer to pass to new_connection. This is the first step of fixing the non-interactivity limitations of SshProxy. But it's also the easiest step: the next ones will be more involved.
2021-09-13 16:17:20 +00:00
false, true, false, false, &conn->plug, conf,
Pass an Interactor to new_connection(). Thanks to the previous commit, this new parameter can replace two of the existing ones: instead of passing a LogPolicy and a Seat, we now pass just an Interactor, from which any proxy implementation can extract the LogPolicy and the Seat anyway if they need it.
2021-10-30 16:36:52 +00:00
NULL);
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
if ((err = sk_socket_error(s)) != NULL) {
fprintf(stderr, "pageant: unable to connect to X server: %s", err);
exit(1);
}
greeting = x11_make_greeting('B', 11, 0, disp->localauthproto,
disp->localauthdata,
disp->localauthdatalen,
NULL, 0, &greetinglen);
sk_write(s, greeting, greetinglen);
smemclr(greeting, greetinglen);
sfree(greeting);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
pageant_fork_and_print_env(false);
Unix Pageant: -T option, tying lifetime to controlling tty. This is intended to be a useful mode when you want to run an ssh agent in a terminal session with no X11 available. You just execute a command along the lines of eval $(pageant -T), and then Pageant will run in the background for the rest of that terminal session - and when the terminal session ends, so that Pageant loses its controlling tty, it will take that as the signal to shut down. So, no need to manually kill it, and unlike 'pageant --exec $SHELL', you can also do this half way through a session if you don't realise until later that you need an SSH agent, without losing any shell command history or other shell context that you've accumulated so far in the session. Unfortunately, I haven't been able to find any reliable way to actually implement this -T mode, short of having Pageant wake up at regular intervals and try to open /dev/tty to see if it's still there. I had hoped that I could arrange to reliably get SIGHUP, or select on /dev/tty for exceptional conditions, or some such, but nothing I've tried along those lines seems to work.
2015-05-08 18:50:48 +00:00
} else if (life == LIFE_TTY) {
schedule_timer(TTY_LIFE_POLL_INTERVAL,
tty_life_timer, &dummy_timer_ctx);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
pageant_fork_and_print_env(true);
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
} else if (life == LIFE_PERM) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
pageant_fork_and_print_env(false);
Support running UNIX Pageant in foreground mode, without debugging output This new mode makes it easy to run Pageant as a "supervised" instance, e.g. as part of a test harness for other programs interacting with an SSH agent, which is the original use case. Because Pageant is then running as a child process of the supervisor, the operating system notifies the supervisor of the child's aliveness without resorting to PIDs or socket addresses, both of which may principally run stale and/or get recycled.
2024-09-18 18:04:31 +00:00
} else if (life == LIFE_FOREGROUND) {
pageant_print_env(getpid());
pageant --foreground: close stdout after printing env setup. This is a small refinement of my own to Marco Ricci's new mode introduced by the previous commit. If Pageant is being run by a parent process intending to make requests to it, then it's probably put a pipe on Pageant's stdout, and will be reading from that pipe to retrieve the environment setup commands. So it needs to know when it's read enough. Closing stdout immediately makes this as easy as possible, freeing the parent process of the need to count lines of output (and also know how many lines to expect): it can simply read until there's no more data. This also means there's no need to make stdout line-buffered, of course – the fclose will flush it anyway.
2024-09-23 08:16:14 +00:00
/* Close stdout, so that a parent process at the other end of a pipe
* can do the simple thing of reading up to EOF */
fclose(stdout);
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
} else if (life == LIFE_DEBUG) {
Unix Pageant: make stdout line-buffered in --debug mode. My normal usage of --debug is to run it in a terminal, where it starts by printing its SSH_AUTH_SOCK setting for me to paste into another terminal to run test commands, and then follows that with diagnostic logging of the requests it's receiving. But if you'd rather get that diagnostic information in some location other than a terminal – say, sent to a file which you're viewing in 'less' so that you can search back and forth in it, or piped to another machine because your test requests are going to come from somewhere out of sight of your monitor – then you might run 'pageant --debug' with its stdout being a pipe or a file rather than a terminal, in which case the standard stdio policy will make it unbuffered, and the diagnostics won't show up in a timely manner. The one-line code change is due to Marco Ricci, who had a rather different motivation.
2024-09-23 08:13:16 +00:00
/* Force stdout to be line-buffered in preference to unbuffered, so
* that if diagnostic output is being piped somewhere, it will arrive
* promptly at the other end of the pipe */
setvbuf(stdout, NULL, _IOLBF, 0);
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
pageant_print_env(getpid());
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
upc->logfp = stdout;
struct termios orig_termios;
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
upc->passphrase_fd = fileno(stdin);
if (tcgetattr(upc->passphrase_fd, &orig_termios) == 0) {
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
struct termios new_termios = orig_termios;
new_termios.c_lflag &= ~(ECHO | ECHOE | ECHOK | ECHONL | ICANON);
/*
* Try to set up a watchdog process that will restore
* termios if we crash or are killed. If successful, turn
* off echo, for runtime passphrase prompts.
*/
int pipefd[2];
if (pipe(pipefd) == 0) {
pid_t pid = fork();
if (pid == 0) {
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
tcsetattr(upc->passphrase_fd, TCSADRAIN, &new_termios);
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
close(pipefd[1]);
char buf[4096];
while (read(pipefd[0], buf, sizeof(buf)) > 0);
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
tcsetattr(upc->passphrase_fd, TCSADRAIN, &new_termios);
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
_exit(0);
} else if (pid > 0) {
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
upc->prompt_type = RTPROMPT_DEBUG;
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
}
close(pipefd[0]);
if (pid < 0)
close(pipefd[1]);
}
}
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
} else if (life == LIFE_EXEC) {
pid_t agentpid, pid;
agentpid = getpid();
uxpgnt: factor out setup_sigchld_handler(). I'm about to need to call this from multiple places.
2020-02-08 18:35:37 +00:00
setup_sigchld_handler();
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
pid = fork();
if (pid < 0) {
perror("fork");
exit(1);
} else if (pid == 0) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
setenv("SSH_AUTH_SOCK", socketname, true);
setenv("SSH_AGENT_PID", dupprintf("%d", (int)agentpid), true);
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
execvp(exec_args[0], exec_args);
perror("exec");
_exit(127);
} else {
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
upc->termination_pid = pid;
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
}
}
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
if (!upc->logfp)
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
upc->plc.suppress_logging = true;
Put proper logging into Pageant. Now it actually logs all its requests and responses, the fingerprints of keys mentioned in all messages, and so on. I've also added the -v option, which causes Pageant in any mode to direct that logging information to standard error. In --debug mode, however, the logging output goes to standard output instead (because when debugging, that information changes from a side effect to the thing you actually wanted in the first place :-). An internal tweak: the logging functions now take a va_list rather than an actual variadic argument list, so that I can pass it through several functions.
2015-05-06 18:32:26 +00:00
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
cli_main_loop(agent_loop_pw_setup, agent_loop_pw_check,
agent_loop_continue, upc);
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
Clean up Unix Pageant's setup and teardown. I've moved the listening socket setup back to before the lifetime preparations, so in particular we find out that we couldn't bind to the socket _before_ we fork. The only part that really needed to come after lifetime setup was the logging setup, so that's now a separate function called later. Also, the random exit(0)s in silly places like x11_closing have turned into setting a time_to_die flag, so that all clean exits funnel back to the end of main() which at least tries to tidy up a bit afterwards. (Finally, fixed a small bug in testing the return value of waitpid(), which only showed up once we didn't exit(0) after the first wait. Ahem.)
2015-05-07 18:04:25 +00:00
/*
Factor out common code from Unix CLI main loops. Unix Plink, Unix Pageant in server mode, Uppity, and the post- connection form of PSFTP's command-line reading code all had very similar loops in them, which run a pollwrapper and mediate between that, timers, and toplevel callbacks. It's long past time the common code between all of those became a reusable shared routine. So, this commit introduces uxcliloop.c, and turns all the previous copies of basically the same loop into a call to cli_main_loop with various callback functions to configure the parts that differ.
2020-02-07 19:14:32 +00:00
* Before terminating, clean up our Unix socket file if possible.
Clean up Unix Pageant's setup and teardown. I've moved the listening socket setup back to before the lifetime preparations, so in particular we find out that we couldn't bind to the socket _before_ we fork. The only part that really needed to come after lifetime setup was the logging setup, so that's now a separate function called later. Also, the random exit(0)s in silly places like x11_closing have turned into setting a time_to_die flag, so that all clean exits funnel back to the end of main() which at least tries to tidy up a bit afterwards. (Finally, fixed a small bug in testing the return value of waitpid(), which only showed up once we didn't exit(0) after the first wait. Ahem.)
2015-05-07 18:04:25 +00:00
*/
if (unlink(socketname) < 0) {
fprintf(stderr, "pageant: %s: %s\n", socketname, strerror(errno));
exit(1);
}
Add an assortment of missing frees and closes. Coverity's resource-leak checker is on the ball as usual.
2017-02-14 20:42:26 +00:00
Fix benign memory leak in uxpgnt. No real need - when we fail to free this strbuf, we were about to exit the whole process anyway - but it keeps Leak Sanitiser off my back, as usual.
2020-02-15 15:55:30 +00:00
strbuf_free(upc->prompt_buf);
Add an assortment of missing frees and closes. Coverity's resource-leak checker is on the ball as usual.
2017-02-14 20:42:26 +00:00
conf_free(conf);
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
}
int main(int argc, char **argv)
{
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 doing_opts = true;
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
keyact curr_keyact = KEYACT_AGENT_LOAD;
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
const char *standalone_askpass_prompt = NULL;
Unix Pageant: add a --symlink option. I've often found it useful that you can make symlinks to Unix-domain sockets, and then connect() on the symlink path will redirect to the original socket. This commit adds an option to Unix Pageant which will make it symlink its socket path to a link location of your choice. My initial use case is when running Pageant in debug mode during development: if you run a new copy of it every few minutes after making a code change, then it's annoying to have it change its socket path every time so you have to keep pasting its setup command into your test shell. Not any more! Now you can run 'pageant --debug --symlink fixed-location', and then your test shell can point its SSH_AUTH_SOCK at the fixed location all the time. There are very likely other use cases too, but that's the one that motivated me to add the option.
2020-02-02 18:52:10 +00:00
const char *symlink_path = NULL;
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
FILE *logfp = NULL;
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
Arm: turn on PSTATE.DIT if available and needed. DIT, for 'Data-Independent Timing', is a bit you can set in the processor state on sufficiently new Arm CPUs, which promises that a long list of instructions will deliberately avoid varying their timing based on the input register values. Just what you want for keeping your constant-time crypto primitives constant-time. As far as I'm aware, no CPU has _yet_ implemented any data-dependent optimisations, so DIT is a safety precaution against them doing so in future. It would be embarrassing to be caught without it if a future CPU does do that, so we now turn on DIT in the PuTTY process state. I've put a call to the new enable_dit() function at the start of every main() and WinMain() belonging to a program that might do cryptography (even testcrypt, in case someone uses it for something!), and in case I missed one there, also added a second call at the first moment that any cryptography-using part of the code looks as if it might become active: when an instance of the SSH protocol object is configured, when the system PRNG is initialised, and when selecting any cryptographic authentication protocol in an HTTP or SOCKS proxy connection. With any luck those precautions between them should ensure it's on whenever we need it. Arm's own recommendation is that you should carefully choose the granularity at which you enable and disable DIT: there's a potential time cost to turning it on and off (I'm not sure what, but plausibly something of the order of a pipeline flush), so it's a performance hit to do it _inside_ each individual crypto function, but if CPUs start supporting significant data-dependent optimisation in future, then it will also become a noticeable performance hit to just leave it on across the whole process. So you'd like to do it somewhere in the middle: for example, you might turn on DIT once around the whole process of verifying and decrypting an SSH packet, instead of once for decryption and once for MAC. With all respect to that recommendation as a strategy for maximum performance, I'm not following it here. I turn on DIT at the start of the PuTTY process, and then leave it on. Rationale: 1. PuTTY is not otherwise a performance-critical application: it's not likely to max out your CPU for any purpose _other_ than cryptography. The most CPU-intensive non-cryptographic thing I can imagine a PuTTY process doing is the complicated computation of font rendering in the terminal, and that will normally be cached (you don't recompute each glyph from its outline and hints for every time you display it). 2. I think a bigger risk lies in accidental side channels from having DIT turned off when it should have been on. I can imagine lots of causes for that. Missing a crypto operation in some unswept corner of the code; confusing control flow (like my coroutine macros) jumping with DIT clear into the middle of a region of code that expected DIT to have been set at the beginning; having a reference counter of DIT requests and getting it out of sync. In a more sophisticated programming language, it might be possible to avoid the risk in #2 by cleverness with the type system. For example, in Rust, you could have a zero-sized type that acts as a proof token for DIT being enabled (it would be constructed by a function that also sets DIT, have a Drop implementation that clears DIT, and be !Send so you couldn't use it in a thread other than the one where DIT was set), and then you could require all the actual crypto functions to take a DitToken as an extra parameter, at zero runtime cost. Then "oops I forgot to set DIT around this piece of crypto" would become a compile error. Even so, you'd have to take some care with coroutine-structured code (what happens if a Rust async function yields while holding a DIT token?) and with nesting (if you have two DIT tokens, you don't want dropping the inner one to clear DIT while the outer one is still there to wrongly convince callees that it's set). Maybe in Rust you could get this all to work reliably. But not in C! DIT is an optional feature of the Arm architecture, so we must first test to see if it's supported. This is done the same way as we already do for the various Arm crypto accelerators: on ELF-based systems, check the appropriate bit in the 'hwcap' words in the ELF aux vector; on Mac, look for an appropriate sysctl flag. On Windows I don't know of a way to query the DIT feature, _or_ of a way to write the necessary enabling instruction in an MSVC-compatible way. I've _heard_ that it might not be necessary, because Windows might just turn on DIT unconditionally and leave it on, in an even more extreme version of my own strategy. I don't have a source for that - I heard it by word of mouth - but I _hope_ it's true, because that would suit me very well! Certainly I can't write code to enable DIT without knowing (a) how to do it, (b) how to know if it's safe. Nonetheless, I've put the enable_dit() call in all the right places in the Windows main programs as well as the Unix and cross-platform code, so that if I later find out that I _can_ put in an explicit enable of DIT in some way, I'll only have to arrange to set HAVE_ARM_DIT and compile the enable_dit() function appropriately.
2024-12-19 08:47:08 +00:00
enable_dit();
uxpgnt: enable runtime prompts in -X mode. This makes all the new deferred-decryption business actually _useful_ for the first time: you can now load an encrypted key file and then get a prompt to decrypt it on first use, without Pageant being in the low-usability debug mode. Currently, the option to present runtime prompts is enabled if Pageant is running with an X display detected, regardless of lifetime mode.
2020-02-08 18:36:09 +00:00
progname = argv[0];
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
/*
* Process the command line.
*/
while (--argc > 0) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *p = *++argv;
if (*p == '-' && doing_opts) {
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
if (!strcmp(p, "-V") || !strcmp(p, "--version")) {
version();
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else if (!strcmp(p, "--help")) {
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
usage();
exit(0);
} else if (!strcmp(p, "-v")) {
Unix Pageant: implement runtime prompts in debug mode. This is the easiest place to implement _something_ that will work as a runtime passphrase prompt, which means I get to use it to test the code I'm about to add to the Pageant core to make use of those prompts. Once that's working, we can think about adding prompts for the 'proper' usage modes. The debug-mode passphrase prompts are implemented by simply reading from standard input, having emitted a log message mentioning that a prompt is impending. We put standard input into non-echoing mode, but otherwise don't print any visible prompt (because standard output will in general receive further log messages, which would break it anyway). This is only just good enough for initial testing. In particular, it won't cope if two prompts are in flight at the same time. But good enough for initial testing is better than nothing!
2020-02-02 16:43:58 +00:00
logfp = stderr;
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
} else if (!strcmp(p, "-a")) {
curr_keyact = KEYACT_CLIENT_ADD;
} else if (!strcmp(p, "-d")) {
curr_keyact = KEYACT_CLIENT_DEL;
Unix Pageant: support -r and -R options to re-encrypt. This links up the new re-encryption facilities to the Unix Pageant client-mode command line. Analogously to -d and -D, 'pageant -r key-id' re-encrypts a single key, and 'pageant -R' re-encrypts everything.
2020-02-15 16:40:19 +00:00
} else if (!strcmp(p, "-r")) {
curr_keyact = KEYACT_CLIENT_REENCRYPT;
Support sh/csh syntax switching for Unix Pageant.
2016-03-25 16:43:59 +00:00
} else if (!strcmp(p, "-s")) {
shell_type = SHELL_SH;
} else if (!strcmp(p, "-c")) {
shell_type = SHELL_CSH;
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
} else if (!strcmp(p, "-D")) {
add_keyact(KEYACT_CLIENT_DEL_ALL, NULL);
Unix Pageant: support -r and -R options to re-encrypt. This links up the new re-encryption facilities to the Unix Pageant client-mode command line. Analogously to -d and -D, 'pageant -r key-id' re-encrypts a single key, and 'pageant -R' re-encrypts everything.
2020-02-15 16:40:19 +00:00
} else if (!strcmp(p, "-R")) {
add_keyact(KEYACT_CLIENT_REENCRYPT_ALL, NULL);
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
} else if (!strcmp(p, "-l")) {
add_keyact(KEYACT_CLIENT_LIST, NULL);
Unix Pageant: provide public-key extraction options. I've decided against implementing an option exactly analogous to 'ssh-add -L' (printing the full public key of everything in the agent). Instead, you can identify a specific key to display in full, by any of the same means -d lets you use, and then print it in either of the public key formats we support.
2015-05-12 13:48:32 +00:00
} else if (!strcmp(p, "--public")) {
curr_keyact = KEYACT_CLIENT_PUBLIC;
Unix Pageant: add alias '-L' for '--private-openssh'. Matches the -L option in Unix PuTTYgen, and is much easier to type.
2018-06-03 14:38:57 +00:00
} else if (!strcmp(p, "--public-openssh") || !strcmp(p, "-L")) {
Unix Pageant: provide public-key extraction options. I've decided against implementing an option exactly analogous to 'ssh-add -L' (printing the full public key of everything in the agent). Instead, you can identify a specific key to display in full, by any of the same means -d lets you use, and then print it in either of the public key formats we support.
2015-05-12 13:48:32 +00:00
curr_keyact = KEYACT_CLIENT_PUBLIC_OPENSSH;
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
} else if (!strcmp(p, "-X")) {
life = LIFE_X11;
} else if (!strcmp(p, "-T")) {
life = LIFE_TTY;
Unix Pageant: revise --encrypted and -E CLI options. I've decided that it was a mistake to use -E as the option for adding keys encrypted, because it's better to use it as a fingerprint type selector for the Pageant client side. That way it works the same as command-line PuTTYgen, and also OpenSSH ssh-add (and ssh-keygen). What spelling(s) to use instead for the option to add keys encrypted? Obviously, the same ones I've just decided on for Windows Pageant; there's no sensible reason to make them different.
2021-04-03 09:30:27 +00:00
} else if (!strcmp(p, "--no-decrypt") ||
!strcmp(p, "-no-decrypt") ||
!strcmp(p, "--no_decrypt") ||
!strcmp(p, "-no_decrypt") ||
!strcmp(p, "--nodecrypt") ||
!strcmp(p, "-nodecrypt") ||
!strcmp(p, "--encrypted") ||
!strcmp(p, "-encrypted")) {
Unix Pageant: -E option to load key files encrypted. This applies to both server modes ('pageant -E key.ppk [lifetime]') and client mode ('pageant -a -E key.ppk'). I'm not completely confident that the CLI syntax is actually right yet, but for the moment, it's enough that it _exists_. Now I don't have to test the encrypted-key loading via manually mocked-up agent requests.
2020-02-08 17:28:46 +00:00
if (curr_keyact == KEYACT_AGENT_LOAD)
curr_keyact = KEYACT_AGENT_LOAD_ENCRYPTED;
else if (curr_keyact == KEYACT_CLIENT_ADD)
curr_keyact = KEYACT_CLIENT_ADD_ENCRYPTED;
else {
Unix Pageant: fix usage message about --encrypted. If you specified --encrypted or one of its synonyms while not adding keys, Pageant would start going on about the unrelated -E option for some reason.
2024-11-17 14:30:08 +00:00
fprintf(stderr, "pageant: unexpected %s while not adding "
"keys\n", p);
Unix Pageant: -E option to load key files encrypted. This applies to both server modes ('pageant -E key.ppk [lifetime]') and client mode ('pageant -a -E key.ppk'). I'm not completely confident that the CLI syntax is actually right yet, but for the moment, it's enough that it _exists_. Now I don't have to test the encrypted-key loading via manually mocked-up agent requests.
2020-02-08 17:28:46 +00:00
exit(1);
}
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
} else if (!strcmp(p, "--debug")) {
life = LIFE_DEBUG;
Support running UNIX Pageant in foreground mode, without debugging output This new mode makes it easy to run Pageant as a "supervised" instance, e.g. as part of a test harness for other programs interacting with an SSH agent, which is the original use case. Because Pageant is then running as a child process of the supervisor, the operating system notifies the supervisor of the child's aliveness without resorting to PIDs or socket addresses, both of which may principally run stale and/or get recycled.
2024-09-18 18:04:31 +00:00
} else if (!strcmp(p, "--foreground")) {
life = LIFE_FOREGROUND;
Unix Pageant: --test-sign client option. This reads data from standard input, turns it into an SSH-2 sign request, and writes the resulting signature blob to standard output. I don't really anticipate many uses for this other than testing. But it _is_ convenient for testing changes to Pageant itself: it lets me ask for a signature without first having to construct a pointless SSH session that will accept the relevant key.
2020-02-09 21:56:21 +00:00
} else if (!strcmp(p, "--test-sign")) {
curr_keyact = KEYACT_CLIENT_SIGN;
sign_flags = 0;
} else if (strstartswith(p, "--test-sign-with-flags=")) {
curr_keyact = KEYACT_CLIENT_SIGN;
sign_flags = atoi(p + strlen("--test-sign-with-flags="));
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
} else if (!strcmp(p, "--permanent")) {
life = LIFE_PERM;
} else if (!strcmp(p, "--exec")) {
life = LIFE_EXEC;
/* Now all subsequent arguments go to the exec command. */
if (--argc > 0) {
exec_args = ++argv;
argc = 0; /* force end of option processing */
} else {
fprintf(stderr, "pageant: expected a command "
"after --exec\n");
exit(1);
}
Unix Pageant: options to select askpass type. Mostly for debugging purposes, because I'm tired of having to use 'setsid' to force Pageant to select the GUI passphrase prompt when I'm trying to fix bugs in gtkask.c. But I can also imagine situations in which the ability to force a GUI prompt window might be useful to end users, for example if the process does _technically_ have a controlling terminal but it's not a user-visible one (say, in the back end of some automation tool like expect(1)). For symmetry, I also provide an option to force the tty prompt. That's less obviously useful, because that's already the preferred prompt type when both methods are available - so the only use for it would be if you wanted to ensure that Pageant didn't _accidentally_ try to launch a GUI prompt, and aborted with an error if it couldn't use a tty prompt.
2018-05-14 06:36:05 +00:00
} else if (!strcmp(p, "--tty-prompt")) {
prompt_type = PROMPT_TTY;
} else if (!strcmp(p, "--gui-prompt")) {
prompt_type = PROMPT_GUI;
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
} else if (!strcmp(p, "--askpass")) {
if (--argc > 0) {
standalone_askpass_prompt = *++argv;
} else {
fprintf(stderr, "pageant: expected a prompt message "
"after --askpass\n");
exit(1);
}
Unix Pageant: add a --symlink option. I've often found it useful that you can make symlinks to Unix-domain sockets, and then connect() on the symlink path will redirect to the original socket. This commit adds an option to Unix Pageant which will make it symlink its socket path to a link location of your choice. My initial use case is when running Pageant in debug mode during development: if you run a new copy of it every few minutes after making a code change, then it's annoying to have it change its socket path every time so you have to keep pasting its setup command into your test shell. Not any more! Now you can run 'pageant --debug --symlink fixed-location', and then your test shell can point its SSH_AUTH_SOCK at the fixed location all the time. There are very likely other use cases too, but that's the one that motivated me to add the option.
2020-02-02 18:52:10 +00:00
} else if (!strcmp(p, "--symlink")) {
if (--argc > 0) {
symlink_path = *++argv;
} else {
fprintf(stderr, "pageant: expected a pathname "
"after --symlink\n");
exit(1);
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
}
Unix Pageant: revise --encrypted and -E CLI options. I've decided that it was a mistake to use -E as the option for adding keys encrypted, because it's better to use it as a fingerprint type selector for the Pageant client side. That way it works the same as command-line PuTTYgen, and also OpenSSH ssh-add (and ssh-keygen). What spelling(s) to use instead for the option to add keys encrypted? Obviously, the same ones I've just decided on for Windows Pageant; there's no sensible reason to make them different.
2021-04-03 09:30:27 +00:00
} else if (!strcmp(p, "-E") || !strcmp(p, "--fptype")) {
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
const char *keyword;
if (--argc > 0) {
keyword = *++argv;
} else {
pageant: Fix a usage message.
2021-03-27 18:21:21 +00:00
fprintf(stderr, "pageant: expected a type string "
Unix Pageant: revise --encrypted and -E CLI options. I've decided that it was a mistake to use -E as the option for adding keys encrypted, because it's better to use it as a fingerprint type selector for the Pageant client side. That way it works the same as command-line PuTTYgen, and also OpenSSH ssh-add (and ssh-keygen). What spelling(s) to use instead for the option to add keys encrypted? Obviously, the same ones I've just decided on for Windows Pageant; there's no sensible reason to make them different.
2021-04-03 09:30:27 +00:00
"after %s\n", p);
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
exit(1);
}
if (!strcmp(keyword, "md5"))
key_list_fptype = SSH_FPTYPE_MD5;
else if (!strcmp(keyword, "sha256"))
key_list_fptype = SSH_FPTYPE_SHA256;
Certificate-aware handling of key fingerprints. OpenSSH, when called on to give the fingerprint of a certified public key, will in many circumstances generate the hash of the public blob of the _underlying_ key, rather than the hash of the full certificate. I think the hash of the certificate is also potentially useful (if nothing else, it provides a way to tell apart multiple certificates on the same key). But I can also see that it's useful to be able to recognise a key as the same one 'really' (since all certificates on the same key share a private key, so they're unavoidably related). So I've dealt with this by introducing an extra pair of fingerprint types, giving the cross product of {MD5, SHA-256} x {base key only, full certificate}. You can manually select which one you want to see in some circumstances (notably PuTTYgen), and in others (such as diagnostics) both fingerprints will be emitted side by side via the new functions ssh2_double_fingerprint[_blob]. The default, following OpenSSH, is to just fingerprint the base key.
2022-08-05 17:08:59 +00:00
else if (!strcmp(keyword, "md5-cert"))
key_list_fptype = SSH_FPTYPE_MD5_CERT;
else if (!strcmp(keyword, "sha256-cert"))
key_list_fptype = SSH_FPTYPE_SHA256_CERT;
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
else {
fprintf(stderr, "pageant: unknown fingerprint type `%s'\n",
keyword);
exit(1);
Unix Pageant: add a --symlink option. I've often found it useful that you can make symlinks to Unix-domain sockets, and then connect() on the symlink path will redirect to the original socket. This commit adds an option to Unix Pageant which will make it symlink its socket path to a link location of your choice. My initial use case is when running Pageant in debug mode during development: if you run a new copy of it every few minutes after making a code change, then it's annoying to have it change its socket path every time so you have to keep pasting its setup command into your test shell. Not any more! Now you can run 'pageant --debug --symlink fixed-location', and then your test shell can point its SSH_AUTH_SOCK at the fixed location all the time. There are very likely other use cases too, but that's the one that motivated me to add the option.
2020-02-02 18:52:10 +00:00
}
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
} else if (!strcmp(p, "--")) {
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
doing_opts = false;
Unix Pageant: add a --symlink option. I've often found it useful that you can make symlinks to Unix-domain sockets, and then connect() on the symlink path will redirect to the original socket. This commit adds an option to Unix Pageant which will make it symlink its socket path to a link location of your choice. My initial use case is when running Pageant in debug mode during development: if you run a new copy of it every few minutes after making a code change, then it's annoying to have it change its socket path every time so you have to keep pasting its setup command into your test shell. Not any more! Now you can run 'pageant --debug --symlink fixed-location', and then your test shell can point its SSH_AUTH_SOCK at the fixed location all the time. There are very likely other use cases too, but that's the one that motivated me to add the option.
2020-02-02 18:52:10 +00:00
} else {
fprintf(stderr, "pageant: unrecognised option '%s'\n", p);
exit(1);
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
}
} else {
/*
* Non-option arguments (apart from those after --exec,
* which are treated specially above) are interpreted as
* the names of private key files to either add or delete
* from an agent.
*/
add_keyact(curr_keyact, p);
}
}
if (life == LIFE_EXEC && !exec_args) {
fprintf(stderr, "pageant: expected a command with --exec\n");
exit(1);
}
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
if (!display) {
display = getenv("DISPLAY");
if (display && !*display)
display = NULL;
}
/*
* Deal with standalone-askpass mode.
*/
if (standalone_askpass_prompt) {
char *passphrase = askpass(standalone_askpass_prompt);
if (!passphrase)
return 1;
puts(passphrase);
uxpgnt --askpass: explicitly fflush(stdout) on exit. I'm not really sure why that's necessary: by my understanding of the C standard, it shouldn't be. But my observation is that when compiling with {Address,Leak} Sanitiser enabled, pageant --askpass can somehow manage to exit without having actually written the passphrase to its standard output.
2020-02-08 18:57:57 +00:00
fflush(stdout);
Unix Pageant: option to behave like ssh-askpass. Since Pageant contains its own passphrase prompt system rather than delegating it to another process, it's not trivial to use it in other contexts. But having gone to the effort of coming up with my own askpass system that (I think) does a better job at not revealing the length of the password, I _want_ to use it in other contexts where a GUI passphrase or password prompt is needed. Solution: an --askpass option.
2018-05-14 07:08:34 +00:00
smemclr(passphrase, strlen(passphrase));
sfree(passphrase);
return 0;
}
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
/*
* Block SIGPIPE, so that we'll get EPIPE individually on
* particular network connections that go wrong.
*/
putty_signal(SIGPIPE, SIG_IGN);
sk_init();
uxsel_init();
/*
* Now distinguish our two main running modes. Either we're
* actually starting up an agent, in which case we should have a
* lifetime mode, and no key actions of KEYACT_CLIENT_* type; or
* else we're contacting an existing agent to add or remove keys,
* in which case we should have no lifetime mode, and no key
* actions of KEYACT_AGENT_* type.
*/
{
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 has_agent_actions = false;
bool has_client_actions = false;
bool has_lifetime = false;
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
const struct cmdline_key_action *act;
for (act = keyact_head; act; act = act->next) {
if (is_agent_action(act->action))
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
has_agent_actions = true;
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
else
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
has_client_actions = true;
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
}
if (life != LIFE_UNSPEC)
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
has_lifetime = true;
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
if (has_lifetime && has_client_actions) {
Pageant: docs / help for deferred decryption. Also, ensure -E/--fptype in Unix Pageant is (correctly) documented everywhere.
2021-04-05 17:35:38 +00:00
fprintf(stderr, "pageant: client key actions (-a, -d, -D, -r, -R, "
"-l, -L) do not go with an agent lifetime option\n");
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
exit(1);
}
if (!has_lifetime && has_agent_actions) {
fprintf(stderr, "pageant: expected an agent lifetime option with"
" bare key file arguments\n");
exit(1);
}
if (!has_lifetime && !has_client_actions) {
fprintf(stderr, "pageant: expected an agent lifetime option"
" or a client key action\n");
exit(1);
}
if (has_lifetime) {
Unix Pageant: add a --symlink option. I've often found it useful that you can make symlinks to Unix-domain sockets, and then connect() on the symlink path will redirect to the original socket. This commit adds an option to Unix Pageant which will make it symlink its socket path to a link location of your choice. My initial use case is when running Pageant in debug mode during development: if you run a new copy of it every few minutes after making a code change, then it's annoying to have it change its socket path every time so you have to keep pasting its setup command into your test shell. Not any more! Now you can run 'pageant --debug --symlink fixed-location', and then your test shell can point its SSH_AUTH_SOCK at the fixed location all the time. There are very likely other use cases too, but that's the one that motivated me to add the option.
2020-02-02 18:52:10 +00:00
run_agent(logfp, symlink_path);
Unix Pageant: prepare to add client-side modes. I've moved the setup and running of the actual agent server into run_agent(), so that main() is now only command-line parsing and validation. We recognise a collection of new command-line options for talking to an existing agent as a client (analogous to ssh-add), which go to a new run_client() function, but I haven't filled in that function itself yet.
2015-05-11 16:56:37 +00:00
} else if (has_client_actions) {
run_client();
}
}
Clean up Unix Pageant's setup and teardown. I've moved the listening socket setup back to before the lifetime preparations, so in particular we find out that we couldn't bind to the socket _before_ we fork. The only part that really needed to come after lifetime setup was the logging setup, so that's now a separate function called later. Also, the random exit(0)s in silly places like x11_closing have turned into setting a time_to_die flag, so that all clean exits funnel back to the end of main() which at least tries to tidy up a bit afterwards. (Finally, fixed a small bug in testing the return value of waitpid(), which only showed up once we didn't exit(0) after the first wait. Ahem.)
2015-05-07 18:04:25 +00:00
Provide a Unix port of Pageant. This is much more like ssh-agent than the Windows version is - it sets SSH_AUTH_SOCK and SSH_AGENT_PID as its means of being found by other processes, rather than Windows Pageant's approach of establishing itself in a well-known location. But the actual agent code is the same as Windows Pageant. For the moment, this is an experimental utility and I don't expect it to be useful to many people; its immediate use to me is that it provides a way to test and debug the agent code on Unix, and also to use the agent interface as a convenient way to exercise public key functions I want to debug. And of course it means I can be constantly using and testing my own code, on whatever platform I happen to be using. In the further future, I have a list of possible features I might add to it, but I don't know which ones I'll decide are worthwhile. One feature I've already put in is a wider range of lifetime management options than ssh-agent: the -X mode causes Pageant to make a connection to your X display, and automatically terminate when that connection closes, so that it has the same lifetime as your X session without having to do the cumbersome trick of exec()ing the subsequent session-management process.
2015-05-05 19:16:23 +00:00
return 0;
}
Reference in New Issue Copy Permalink