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
3c6ab5bbb7
putty-source/unix/uxpgnt.c

1432 lines
45 KiB
C
Raw 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]);
/*
* See comment in fork_and_exec_self() in gtkmain.c.
*/
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(
PageantListenerClient *plc, PageantClientDialogId *dlgid, const char *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
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 */
switch (upc->prompt_type) {
case RTPROMPT_UNAVAILABLE:
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);
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);
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; }
FontSpec *platform_default_fontspec(const char *name) { return fontspec_new(""); }
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);
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("Usage: pageant <lifetime> [key files]\n");
printf(" pageant [key files] --exec <command> [args]\n");
printf(" pageant -a [key files]\n");
printf(" pageant -d [key identifiers]\n");
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");
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 -l\n");
printf(" pageant -D\n");
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");
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");
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");
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
printf(" --tty-prompt force tty-based passphrase prompt (in -a mode)\n");
printf(" --gui-prompt force GUI-based passphrase prompt (in -a mode)\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
exit(1);
}
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"
const char *const appname = "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
/* Stub functions to permit linking against x11fwd.c. These never get
* used, because in LIFE_X11 mode we connect to the X server using a
* straightforward Socket and don't try to create an ersatz SSH
* forwarding too. */
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
void chan_remotely_opened_confirmation(Channel *chan) { }
void chan_remotely_opened_failure(Channel *chan, const char *err) { }
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 chan_default_want_close(Channel *chan, bool s, bool r) { return false; }
bool chan_no_exit_status(Channel *ch, int s) { return false; }
bool chan_no_exit_signal(Channel *ch, ptrlen s, bool c, ptrlen m)
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; }
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 chan_no_exit_signal_numeric(Channel *ch, int s, bool c, ptrlen m)
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; }
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 chan_no_run_shell(Channel *chan) { return false; }
bool chan_no_run_command(Channel *chan, ptrlen command) { return false; }
bool chan_no_run_subsystem(Channel *chan, ptrlen subsys) { return false; }
bool chan_no_enable_x11_forwarding(
Channel *chan, bool oneshot, ptrlen authproto, ptrlen authdata,
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
unsigned screen_number) { return false; }
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 chan_no_enable_agent_forwarding(Channel *chan) { return false; }
bool chan_no_allocate_pty(
Server prep: parse a lot of new channel requests. ssh2connection.c now knows how to unmarshal the message formats for all the channel requests we'll need to handle when we're the server and a client sends them. Each one is translated into a call to a new method in the Channel vtable, which is implemented by a trivial 'always fail' routine in every channel type we know about so far.
2018-10-20 20:48:49 +00:00
Channel *chan, ptrlen termtype, unsigned width, unsigned height,
unsigned pixwidth, unsigned pixheight, struct ssh_ttymodes modes)
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; }
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 chan_no_set_env(Channel *chan, ptrlen var, ptrlen value) { return false; }
bool chan_no_send_break(Channel *chan, unsigned length) { return false; }
bool chan_no_send_signal(Channel *chan, ptrlen signame) { return false; }
bool chan_no_change_window_size(
Server prep: parse a lot of new channel requests. ssh2connection.c now knows how to unmarshal the message formats for all the channel requests we'll need to handle when we're the server and a client sends them. Each one is translated into a call to a new method in the Channel vtable, which is implemented by a trivial 'always fail' routine in every channel type we know about so far.
2018-10-20 20:48:49 +00:00
Channel *chan, unsigned width, unsigned height,
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
unsigned pixwidth, unsigned pixheight) { return false; }
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 chan_no_request_response(Channel *chan, bool success) {}
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +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
/*
* These functions are part of the plug for our connection to the X
* display, so they do get called. They needn't actually do anything,
* except that x11_closing has to signal back to the main loop that
* it's time to terminate.
*/
Make the plug_log type code into an enum. Those magic numbers have been annoying for ages. Now they have names that I havea fighting chance of remembering the meanings of.
2020-02-07 19:17:45 +00:00
static void x11_log(Plug *p, PlugLogType type, SockAddr *addr, int port,
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
const char *error_msg, int error_code) {}
Make lots of 'int' length fields into size_t. This is a general cleanup which has been overdue for some time: lots of length fields are now the machine word type rather than the (in practice) fixed 'int'.
2019-02-06 20:42:44 +00:00
static void x11_receive(Plug *plug, int urgent, const char *data, size_t len) {}
static void x11_sent(Plug *plug, size_t bufsize) {}
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
static void x11_closing(Plug *plug, const char *error_msg, int error_code,
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
bool calling_back)
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
{
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();
} 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 {
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_UNSPEC, LIFE_X11, LIFE_TTY, LIFE_DEBUG, LIFE_PERM, LIFE_EXEC
} 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: 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
{
int ret;
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);
Remove unused params from console_get_userpass_input. NFC: this is a preliminary refactoring, intended to make my life easier when I start changing around the APIs used to pass user keyboard input around. The fewer functions even _have_ such an API, the less I'll have to do at that point.
2018-05-18 06:22:56 +00:00
ret = console_get_userpass_input(p);
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
assert(ret >= 0);
if (!ret) {
perror("pageant: unable to read passphrase");
free_prompts(p);
return NULL;
} 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;
}
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
void key_list_callback(void *ctx, const char *fingerprint, const char *comment,
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)";
printf("%s %s%s\n", fingerprint, 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 -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;
};
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_fingerprint_string(const char *string, const char *fingerprint)
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;
/* Find the hash in the fingerprint string. It'll be the word at the end. */
hash = strrchr(fingerprint, ' ');
assert(hash);
hash++;
/* Now see if the search string is a prefix of the full hash,
* neglecting colons and case differences. */
while (1) {
while (*string == ':') string++;
while (*hash == ':') hash++;
if (!*string)
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: 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 (tolower((unsigned char)*string) != tolower((unsigned char)*hash))
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: 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
string++;
hash++;
}
}
void key_find_callback(void *vctx, const char *fingerprint,
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)) ||
(ctx->match_fp && match_fingerprint_string(ctx->string, fingerprint)))
{
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 -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 -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;
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 = {
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 = x11_log,
.closing = x11_closing,
.receive = x11_receive,
.sent = x11_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,
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
false, true, false, false, &conn->plug, conf);
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);
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) {
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
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: -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
} else if (!strcmp(p, "-E")) {
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 {
fprintf(stderr, "pageant: unexpected -E while not adding "
"keys\n");
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;
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: 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) {
fprintf(stderr, "pageant: client key actions (-a, -d, -D, -l, -L)"
" do not go with an agent lifetime option\n");
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