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
9f2e1e6e03
putty-source/pageant.c

2692 lines
84 KiB
C
Raw Normal View History

Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
/*
* pageant.c: cross-platform code to implement Pageant.
*/
#include <stddef.h>
#include <stdlib.h>
#include <assert.h>
#include "putty.h"
Complete rewrite of PuTTY's bignum library. The old 'Bignum' data type is gone completely, and so is sshbn.c. In its place is a new thing called 'mp_int', handled by an entirely new library module mpint.c, with API differences both large and small. The main aim of this change is that the new library should be free of timing- and cache-related side channels. I've written the code so that it _should_ - assuming I haven't made any mistakes - do all of its work without either control flow or memory addressing depending on the data words of the input numbers. (Though, being an _arbitrary_ precision library, it does have to at least depend on the sizes of the numbers - but there's a 'formal' size that can vary separately from the actual magnitude of the represented integer, so if you want to keep it secret that your number is actually small, it should work fine to have a very long mp_int and just happen to store 23 in it.) So I've done all my conditionalisation by means of computing both answers and doing bit-masking to swap the right one into place, and all loops over the words of an mp_int go up to the formal size rather than the actual size. I haven't actually tested the constant-time property in any rigorous way yet (I'm still considering the best way to do it). But this code is surely at the very least a big improvement on the old version, even if I later find a few more things to fix. I've also completely rewritten the low-level elliptic curve arithmetic from sshecc.c; the new ecc.c is closer to being an adjunct of mpint.c than it is to the SSH end of the code. The new elliptic curve code keeps all coordinates in Montgomery-multiplication transformed form to speed up all the multiplications mod the same prime, and only converts them back when you ask for the affine coordinates. Also, I adopted extended coordinates for the Edwards curve implementation. sshecc.c has also had a near-total rewrite in the course of switching it over to the new system. While I was there, I've separated ECDSA and EdDSA more completely - they now have separate vtables, instead of a single vtable in which nearly every function had a big if statement in it - and also made the externally exposed types for an ECDSA key and an ECDH context different. A minor new feature: since the new arithmetic code includes a modular square root function, we can now support the compressed point representation for the NIST curves. We seem to have been getting along fine without that so far, but it seemed a shame not to put it in, since it was suddenly easy. In sshrsa.c, one major change is that I've removed the RSA blinding step in rsa_privkey_op, in which we randomise the ciphertext before doing the decryption. The purpose of that was to avoid timing leaks giving away the plaintext - but the new arithmetic code should take that in its stride in the course of also being careful enough to avoid leaking the _private key_, which RSA blinding had no way to do anything about in any case. Apart from those specific points, most of the rest of the changes are more or less mechanical, just changing type names and translating code into the new API.
2018-12-31 13:53:41 +00:00
#include "mpint.h"
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
#include "ssh.h"
Remove duplicate coroutine macros. pageant.c and sshshare.c each had an extra copy of crBegin and crFinishV, dating from when the main versions were kept in ssh.c where they couldn't be conveniently #included by other modules. Now they're in sshcr.h, where they can be, so there's no need to have extra copies of them anywhere. (But I've left the crGetChar macro in each of those files, because those really are specific to the particular context, referring to an extra variable that clients of the more general sshcr.h macros won't all have.)
2019-02-28 18:05:38 +00:00
#include "sshcr.h"
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
#include "pageant.h"
/*
Clean up the crufty old SSH-1 RSA API. Lots of functions had really generic names (like 'makekey'), or names that missed out an important concept (like 'rsakey_pubblob', which loads a public blob from a _file_ and doesn't generate it from an in-memory representation at all). Also, the opaque 'int order' that distinguishes the two formats of public key blob is now a mnemonic enumeration, and while I'm at it, rsa_ssh1_public_blob takes one of those as an extra argument.
2018-05-24 07:22:44 +00:00
* We need this to link with the RSA code, because rsa_ssh1_encrypt()
* pads its data with random bytes. Since we only use rsa_ssh1_decrypt()
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
* and the signing functions, which are deterministic, this should
* never be called.
*
* If it _is_ called, there is a _serious_ problem, because it
* won't generate true random numbers. So we must scream, panic,
* and exit immediately if that should happen.
*/
Replace random_byte() with random_read(). This is in preparation for a PRNG revamp which will want to have a well defined boundary for any given request-for-randomness, so that it can destroy the evidence afterwards. So no more looping round calling random_byte() and then stopping when we feel like it: now you say up front how many random bytes you want, and call random_read() which gives you that many in one go. Most of the call sites that had to be fixed are fairly mechanical, and quite a few ended up more concise afterwards. A few became more cumbersome, such as mp_random_bits, in which the new API doesn't let me load the random bytes directly into the target integer without triggering undefined behaviour, so instead I have to allocate a separate temporary buffer. The _most_ interesting call site was in the PKCS#1 v1.5 padding code in sshrsa.c (used in SSH-1), in which you need a stream of _nonzero_ random bytes. The previous code just looped on random_byte, retrying if it got a zero. Now I'm doing a much more interesting thing with an mpint, essentially scaling a binary fraction repeatedly to extract a number in the range [0,255) and then adding 1 to it.
2019-01-22 19:43:27 +00:00
void random_read(void *buf, size_t size)
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
{
modalfatalbox("Internal error: attempt to use random numbers in 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 pageant_local = false;
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
struct PageantClientDialogId {
int dummy;
};
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
typedef struct PageantPrivateKeySort PageantPrivateKeySort;
typedef struct PageantPublicKeySort PageantPublicKeySort;
typedef struct PageantPrivateKey PageantPrivateKey;
typedef struct PageantPublicKey PageantPublicKey;
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
typedef struct PageantAsyncOp PageantAsyncOp;
typedef struct PageantAsyncOpVtable PageantAsyncOpVtable;
typedef struct PageantClientRequestNode PageantClientRequestNode;
typedef struct PageantKeyRequestNode PageantKeyRequestNode;
struct PageantClientRequestNode {
PageantClientRequestNode *prev, *next;
};
struct PageantKeyRequestNode {
PageantKeyRequestNode *prev, *next;
};
struct PageantClientInfo {
PageantClient *pc; /* goes to NULL when client is unregistered */
PageantClientRequestNode head;
};
struct PageantAsyncOp {
const PageantAsyncOpVtable *vt;
PageantClientInfo *info;
PageantClientRequestNode cr;
PageantClientRequestId *reqid;
};
struct PageantAsyncOpVtable {
void (*coroutine)(PageantAsyncOp *pao);
void (*free)(PageantAsyncOp *pao);
};
static inline void pageant_async_op_coroutine(PageantAsyncOp *pao)
{ pao->vt->coroutine(pao); }
static inline void pageant_async_op_free(PageantAsyncOp *pao)
{
delete_callbacks_for_context(pao);
pao->vt->free(pao);
}
static inline void pageant_async_op_unlink(PageantAsyncOp *pao)
{
pao->cr.prev->next = pao->cr.next;
pao->cr.next->prev = pao->cr.prev;
}
static inline void pageant_async_op_unlink_and_free(PageantAsyncOp *pao)
{
pageant_async_op_unlink(pao);
pageant_async_op_free(pao);
}
static void pageant_async_op_callback(void *vctx)
{
pageant_async_op_coroutine((PageantAsyncOp *)vctx);
}
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
/*
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
* Master lists of all the keys we have stored, in any form at all.
*
* We store private and public keys in separate lists, because
* multiple public keys can share the same private key (due to one
* having a certificate and the other not, or having more than one
* different certificate). And when we decrypt or re-encrypt a private
* key, we don't really want to faff about doing it multiple times if
* there's more than one public key it goes with. If someone tries to
* re-encrypt a key to make their machine safer against unattended
* access, then it would be embarrassing to find they'd forgotten to
* re-encrypt the _other_ copy of it; conversely, once you've
* decrypted a key, it's pointless to make someone type yet another
* passphrase.
*
* (Causing multiple keys to become decrypted in one go isn't a
* security hole in its own right, because the signatures generated by
* certified and uncertified keys are identical. So an attacker
* gaining access to an agent containing one encrypted and one
* cleartext key with the same private half would still be *able* to
* generate signatures that went with the encrypted one, even if the
* agent refused to hand them out in response to the most obvious kind
* of request.)
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
*/
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
struct PageantPrivateKeySort {
/*
* Information used by the sorting criterion for the private key
* tree.
*/
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
int ssh_version; /* 1 or 2; primary sort key */
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
ptrlen base_pub; /* secondary sort key; never includes a certificate */
};
static int privkey_cmpfn(void *av, void *bv)
{
PageantPrivateKeySort *a = (PageantPrivateKeySort *)av;
PageantPrivateKeySort *b = (PageantPrivateKeySort *)bv;
if (a->ssh_version != b->ssh_version)
return a->ssh_version < b->ssh_version ? -1 : +1;
else
return ptrlen_strcmp(a->base_pub, b->base_pub);
}
struct PageantPublicKeySort {
/*
* Information used by the sorting criterion for the public key
* tree. Begins with the private key sorting criterion, so that
* all the public keys sharing a private key appear adjacent in
* the tree. That's a reasonably sensible order to list them in
* for the user, and more importantly, it makes it easy to
* discover when we're deleting the last public key that goes with
* a particular private one, so as to delete that too. Easier than
* messing about with fragile reference counts.
*/
PageantPrivateKeySort priv;
ptrlen full_pub; /* may match priv.base_pub, or may include a cert */
pageant.c: minor cleanup of struct typedefs. These names are unwieldy enough - and there are about to be several more of them - that I want to keep things organised.
2020-01-25 17:24:17 +00:00
};
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
static int pubkey_cmpfn(void *av, void *bv)
{
PageantPublicKeySort *a = (PageantPublicKeySort *)av;
PageantPublicKeySort *b = (PageantPublicKeySort *)bv;
int c = privkey_cmpfn(&a->priv, &b->priv);
if (c)
return c;
else
return ptrlen_strcmp(a->full_pub, b->full_pub);
}
struct PageantPrivateKey {
PageantPrivateKeySort sort;
strbuf *base_pub; /* the true owner of sort.base_pub */
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
union {
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
RSAKey *rkey; /* if sort.priv.ssh_version == 1 */
ssh_key *skey; /* if sort.priv.ssh_version == 2 */
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
};
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
strbuf *encrypted_key_file;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
/* encrypted_key_comment stores the comment belonging to the
* encrypted key file. This is used when presenting deferred
* decryption prompts, because if the user had encrypted their
* uncert and cert keys with different passphrases, the passphrase
* prompt must reliably signal which file they're supposed to be
* entering the passphrase for. */
char *encrypted_key_comment;
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
bool decryption_prompt_active;
Pageant: move signing requests out into a coroutine. The previous commit introduced the PageantAsyncOp trait, with only one trivial implementation. This one introduces a second implementation used for SSH2_AGENTC_SIGN_REQUEST only, which waits to actually construct the signature until after a callback has happened. This will allow the signing process to be suspended in order to request a dialog box and wait for a user response to decide _how_ to reply. Suspended signing operations relating to a particular key are held in a linked list dangling from the corresponding PageantKey structure. This will allow them all to be found easily if that key should be deleted from the agent: in that situation pending signatures from the key will all return SSH_AGENT_FAILURE. Still no functional change, however: the new coroutine doesn't actually wait for anything, it just contains a comment noting that it could if it wanted to.
2020-01-25 17:25:28 +00:00
PageantKeyRequestNode blocked_requests;
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
PageantClientDialogId dlgid;
Pageant: move signing requests out into a coroutine. The previous commit introduced the PageantAsyncOp trait, with only one trivial implementation. This one introduces a second implementation used for SSH2_AGENTC_SIGN_REQUEST only, which waits to actually construct the signature until after a callback has happened. This will allow the signing process to be suspended in order to request a dialog box and wait for a user response to decide _how_ to reply. Suspended signing operations relating to a particular key are held in a linked list dangling from the corresponding PageantKey structure. This will allow them all to be found easily if that key should be deleted from the agent: in that situation pending signatures from the key will all return SSH_AGENT_FAILURE. Still no functional change, however: the new coroutine doesn't actually wait for anything, it just contains a comment noting that it could if it wanted to.
2020-01-25 17:25:28 +00:00
};
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
static tree234 *privkeytree;
struct PageantPublicKey {
PageantPublicKeySort sort;
strbuf *base_pub; /* the true owner of sort.priv.base_pub */
strbuf *full_pub; /* the true owner of sort.full_pub */
char *comment;
};
static tree234 *pubkeytree;
Pageant: move signing requests out into a coroutine. The previous commit introduced the PageantAsyncOp trait, with only one trivial implementation. This one introduces a second implementation used for SSH2_AGENTC_SIGN_REQUEST only, which waits to actually construct the signature until after a callback has happened. This will allow the signing process to be suspended in order to request a dialog box and wait for a user response to decide _how_ to reply. Suspended signing operations relating to a particular key are held in a linked list dangling from the corresponding PageantKey structure. This will allow them all to be found easily if that key should be deleted from the agent: in that situation pending signatures from the key will all return SSH_AGENT_FAILURE. Still no functional change, however: the new coroutine doesn't actually wait for anything, it just contains a comment noting that it could if it wanted to.
2020-01-25 17:25:28 +00:00
typedef struct PageantSignOp PageantSignOp;
struct PageantSignOp {
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPrivateKey *priv;
Pageant: move signing requests out into a coroutine. The previous commit introduced the PageantAsyncOp trait, with only one trivial implementation. This one introduces a second implementation used for SSH2_AGENTC_SIGN_REQUEST only, which waits to actually construct the signature until after a callback has happened. This will allow the signing process to be suspended in order to request a dialog box and wait for a user response to decide _how_ to reply. Suspended signing operations relating to a particular key are held in a linked list dangling from the corresponding PageantKey structure. This will allow them all to be found easily if that key should be deleted from the agent: in that situation pending signatures from the key will all return SSH_AGENT_FAILURE. Still no functional change, however: the new coroutine doesn't actually wait for anything, it just contains a comment noting that it could if it wanted to.
2020-01-25 17:25:28 +00:00
strbuf *data_to_sign;
unsigned flags;
int crLine;
Pageant: handle agent extension messages more correctly. Reading draft-miller-ssh-agent-04 more carefully, I see that I missed a few things from the extension-message spec. Firstly, there's an extension request "query" which is supposed to list all the extensions you support. Secondly, if you recognise an extension-request name but are then unable to fulfill the request for some other reason, you're supposed to return a new kind of failure message that's distinct from SSH_AGENT_FAILURE, because for extensions, the latter is reserved for "I don't even know what this extension name means at all". I've fixed both of those bugs in Pageant by making a centralised map of known extension names to an enumeration of internal ids, and an array containing the name for each id. So we can reliably answer the "query" extension by iterating over that array, and also use the same array to recognise known extensions up front and give them centralised processing (in particular, resetting the failure-message type) before switching on the particular extension index.
2020-02-10 20:45:31 +00:00
unsigned char failure_type;
Pageant: move signing requests out into a coroutine. The previous commit introduced the PageantAsyncOp trait, with only one trivial implementation. This one introduces a second implementation used for SSH2_AGENTC_SIGN_REQUEST only, which waits to actually construct the signature until after a callback has happened. This will allow the signing process to be suspended in order to request a dialog box and wait for a user response to decide _how_ to reply. Suspended signing operations relating to a particular key are held in a linked list dangling from the corresponding PageantKey structure. This will allow them all to be found easily if that key should be deleted from the agent: in that situation pending signatures from the key will all return SSH_AGENT_FAILURE. Still no functional change, however: the new coroutine doesn't actually wait for anything, it just contains a comment noting that it could if it wanted to.
2020-01-25 17:25:28 +00:00
PageantKeyRequestNode pkr;
PageantAsyncOp pao;
pageant.c: minor cleanup of struct typedefs. These names are unwieldy enough - and there are about to be several more of them - that I want to keep things organised.
2020-01-25 17:24:17 +00:00
};
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
Make the Pageant core serialise GUI requests.
2020-02-08 18:08:20 +00:00
/* Master lock that indicates whether a GUI request is currently in
* progress */
static bool gui_request_in_progress = false;
Pageant: fix concurrent attempts to use an encrypted key. If you had a key stored encrypted in Pageant, and you launched two PuTTY sessions both trying to generate a signature with the key, and then didn't type the passphrase into the async passphrase prompt until after both sessions had made requests, then only one of the requests would be replied to once you decrypted the key. The other would sit there waiting for a response that Pageant never got round to sending. This would also happen in the case where you launched two PuTTY sessions each trying to use a _different_ encrypted key in Pageant, in which case Pageant should have presented the next GUI passphrase box after the first one was dismissed. That didn't happen either. This was the result of two separate bugs in the code. Firstly, when signop_coroutine() noticed that a GUI request was already in progress, it would crReturn without making any arrangement to be called back. Now there's a queue of 'requests blocked on waiting for some GUI prompt to finish'. Secondly, if multiple requests were blocked on the same key, the code that went over the linked list of them had a bug in which it would unblock the _first_ list item in every iteration, instead of unblocking all the items once each.
2022-06-11 11:46:29 +00:00
static PageantKeyRequestNode requests_blocked_on_gui =
{ &requests_blocked_on_gui, &requests_blocked_on_gui };
Make the Pageant core serialise GUI requests.
2020-02-08 18:08:20 +00:00
Pageant: new asynchronous internal APIs. This is a pure refactoring: no functional change expected. This commit introduces two new small vtable-style APIs. One is PageantClient, which identifies a particular client of the Pageant 'core' (meaning the code that handles each individual request). This changes pageant_handle_msg into an asynchronous operation: you pass in an agent request message and an identifier, and at some later point, the got_response method in your PageantClient will be called with the answer (and the same identifier, to allow you to match requests to responses). The trait vtable also contains a logging system. The main importance of PageantClient, and the reason why it has to exist instead of just passing pageant_handle_msg a bare callback function pointer and context parameter, is that it provides robustness if a client stops existing while a request is still pending. You call pageant_unregister_client, and any unfinished requests associated with that client in the Pageant core will be cleaned up, so that you're guaranteed that after the unregister operation, no stray callbacks will happen with a stale pointer to that client. The WM_COPYDATA interface of Windows Pageant is a direct client of this API. The other client is PageantListener, the system that lives in pageant.c and handles stream-based agent connections for both Unix Pageant and the new Windows named-pipe IPC. More specifically, each individual connection to the listening socket is a separate PageantClient, which means that if a socket is closed abruptly or suffers an OS error, that client can be unregistered and any pending requests cancelled without disrupting other connections. Users of PageantListener have a second client vtable they can use, called PageantListenerClient. That contains _only_ logging facilities, and at the moment, only Unix Pageant bothers to use it (and even that only in debugging mode). Finally, internally to the Pageant core, there's a new trait called PageantAsyncOp which describes an agent request in the process of being handled. But at the moment, it has only one trivial implementation, which is handed the full response message already constructed, and on the next toplevel callback, passes it back to the PageantClient.
2020-01-25 17:24:28 +00:00
static void failure(PageantClient *pc, PageantClientRequestId *reqid,
Pageant: handle agent extension messages more correctly. Reading draft-miller-ssh-agent-04 more carefully, I see that I missed a few things from the extension-message spec. Firstly, there's an extension request "query" which is supposed to list all the extensions you support. Secondly, if you recognise an extension-request name but are then unable to fulfill the request for some other reason, you're supposed to return a new kind of failure message that's distinct from SSH_AGENT_FAILURE, because for extensions, the latter is reserved for "I don't even know what this extension name means at all". I've fixed both of those bugs in Pageant by making a centralised map of known extension names to an enumeration of internal ids, and an array containing the name for each id. So we can reliably answer the "query" extension by iterating over that array, and also use the same array to recognise known extensions up front and give them centralised processing (in particular, resetting the failure-message type) before switching on the particular extension index.
2020-02-10 20:45:31 +00:00
strbuf *sb, unsigned char type, const char *fmt, ...);
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
static void fail_requests_for_key(PageantPrivateKey *priv, const char *reason);
static PageantPublicKey *pageant_nth_pubkey(int ssh_version, int i);
Pageant: new asynchronous internal APIs. This is a pure refactoring: no functional change expected. This commit introduces two new small vtable-style APIs. One is PageantClient, which identifies a particular client of the Pageant 'core' (meaning the code that handles each individual request). This changes pageant_handle_msg into an asynchronous operation: you pass in an agent request message and an identifier, and at some later point, the got_response method in your PageantClient will be called with the answer (and the same identifier, to allow you to match requests to responses). The trait vtable also contains a logging system. The main importance of PageantClient, and the reason why it has to exist instead of just passing pageant_handle_msg a bare callback function pointer and context parameter, is that it provides robustness if a client stops existing while a request is still pending. You call pageant_unregister_client, and any unfinished requests associated with that client in the Pageant core will be cleaned up, so that you're guaranteed that after the unregister operation, no stray callbacks will happen with a stale pointer to that client. The WM_COPYDATA interface of Windows Pageant is a direct client of this API. The other client is PageantListener, the system that lives in pageant.c and handles stream-based agent connections for both Unix Pageant and the new Windows named-pipe IPC. More specifically, each individual connection to the listening socket is a separate PageantClient, which means that if a socket is closed abruptly or suffers an OS error, that client can be unregistered and any pending requests cancelled without disrupting other connections. Users of PageantListener have a second client vtable they can use, called PageantListenerClient. That contains _only_ logging facilities, and at the moment, only Unix Pageant bothers to use it (and even that only in debugging mode). Finally, internally to the Pageant core, there's a new trait called PageantAsyncOp which describes an agent request in the process of being handled. But at the moment, it has only one trivial implementation, which is handed the full response message already constructed, and on the next toplevel callback, passes it back to the PageantClient.
2020-01-25 17:24:28 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
static void pk_priv_free(PageantPrivateKey *priv)
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (priv->base_pub)
strbuf_free(priv->base_pub);
if (priv->sort.ssh_version == 1 && priv->rkey) {
freersakey(priv->rkey);
sfree(priv->rkey);
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (priv->sort.ssh_version == 2 && priv->skey) {
ssh_key_free(priv->skey);
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (priv->encrypted_key_file)
strbuf_free(priv->encrypted_key_file);
if (priv->encrypted_key_comment)
sfree(priv->encrypted_key_comment);
fail_requests_for_key(priv, "key deleted from Pageant while signing "
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
"request was pending");
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
sfree(priv);
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
}
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
static void pk_pub_free(PageantPublicKey *pub)
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (pub->full_pub)
strbuf_free(pub->full_pub);
sfree(pub->comment);
sfree(pub);
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
}
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
static strbuf *makeblob1(RSAKey *rkey)
{
strbuf *blob = strbuf_new();
rsa_ssh1_public_blob(BinarySink_UPCAST(blob), rkey,
RSA_SSH1_EXPONENT_FIRST);
return blob;
}
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
static strbuf *makeblob2full(ssh_key *key)
{
strbuf *blob = strbuf_new();
ssh_key_public_blob(key, BinarySink_UPCAST(blob));
return blob;
}
static strbuf *makeblob2base(ssh_key *key)
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
{
strbuf *blob = strbuf_new();
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
ssh_key_public_blob(ssh_key_base_key(key), BinarySink_UPCAST(blob));
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
return blob;
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
static PageantPrivateKey *pub_to_priv(PageantPublicKey *pub)
{
PageantPrivateKey *priv = find234(privkeytree, &pub->sort.priv, NULL);
assert(priv && "Public and private trees out of sync!");
return priv;
}
static PageantPublicKey *findpubkey1(RSAKey *reqkey)
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
{
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
strbuf *blob = makeblob1(reqkey);
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKeySort sort;
sort.priv.ssh_version = 1;
sort.priv.base_pub = ptrlen_from_strbuf(blob);
sort.full_pub = ptrlen_from_strbuf(blob);
PageantPublicKey *toret = find234(pubkeytree, &sort, NULL);
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
strbuf_free(blob);
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
return toret;
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
/*
* Constructs the base_pub element of a PageantPublicKeySort, starting
* from full_pub. This may involve allocating a strbuf to store it in,
* which must survive until after you've finished using the resulting
* PageantPublicKeySort. Hence, the strbuf (if any) is returned from
* this function, and if it's non-NULL then the caller must eventually
* free it.
*/
static strbuf *make_base_pub_2(PageantPublicKeySort *sort)
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
/* Start with the fallback option of making base_pub equal full_pub */
sort->priv.base_pub = sort->full_pub;
/* Now reconstruct a distinct base_pub without a cert, if possible
* and necessary */
strbuf *base_pub = NULL;
BinarySource src[1];
BinarySource_BARE_INIT_PL(src, sort->full_pub);
ptrlen algname = get_string(src);
const ssh_keyalg *alg = find_pubkey_alg_len(algname);
if (alg && alg->is_certificate) {
ssh_key *key = ssh_key_new_pub(alg, sort->full_pub);
if (key) {
base_pub = strbuf_new();
ssh_key_public_blob(ssh_key_base_key(key),
BinarySink_UPCAST(base_pub));
sort->priv.base_pub = ptrlen_from_strbuf(base_pub);
ssh_key_free(key);
}
}
return base_pub; /* caller must free once they're done with sort */
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
static PageantPublicKey *findpubkey2(ptrlen full_pub)
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKeySort sort;
sort.priv.ssh_version = 2;
sort.full_pub = full_pub;
strbuf *base_pub = make_base_pub_2(&sort);
PageantPublicKey *toret = find234(pubkeytree, &sort, NULL);
if (base_pub)
strbuf_free(base_pub);
return toret;
}
static int find_first_pubkey_for_version(int ssh_version)
{
PageantPublicKeySort sort;
sort.priv.ssh_version = ssh_version;
sort.priv.base_pub = PTRLEN_LITERAL("");
sort.full_pub = PTRLEN_LITERAL("");
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
int pos;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (findrelpos234(pubkeytree, &sort, NULL, REL234_GE, &pos))
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
return pos;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
return count234(pubkeytree);
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
}
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
static int count_keys(int ssh_version)
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
return (find_first_pubkey_for_version(ssh_version + 1) -
find_first_pubkey_for_version(ssh_version));
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
}
int pageant_count_ssh1_keys(void) { return count_keys(1); }
int pageant_count_ssh2_keys(void) { return count_keys(2); }
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
/*
* Common code to add a key to the trees. We fill in as many fields
* here as we can share between SSH versions: the ptrlens in the
* sorting field, the whole of pub->sort.priv, and the linked list of
* blocked requests.
*/
static bool pageant_add_key_common(PageantPublicKey *pub,
PageantPrivateKey *priv)
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
int ssh_version = priv->sort.ssh_version;
priv->sort.base_pub = ptrlen_from_strbuf(priv->base_pub);
pub->base_pub = strbuf_dup(priv->sort.base_pub);
pub->sort.priv.ssh_version = priv->sort.ssh_version;
pub->sort.priv.base_pub = ptrlen_from_strbuf(pub->base_pub);
pub->sort.full_pub = ptrlen_from_strbuf(pub->full_pub);
priv->blocked_requests.next = priv->blocked_requests.prev =
&priv->blocked_requests;
/*
* Try to add the private key to privkeytree, or combine new parts
* of it with what's already there.
*/
PageantPrivateKey *priv_in_tree = add234(privkeytree, priv);
if (priv_in_tree == priv) {
/* The key wasn't in the tree at all, and we've just added it. */
} else {
/* The key was already in the tree, so we'll be freeing priv. */
if (ssh_version == 2 && priv->skey && !priv_in_tree->skey) {
/* The key was only stored encrypted, and now we have an
* unencrypted version to add to the existing record. */
priv_in_tree->skey = priv->skey;
priv->skey = NULL; /* so pk_priv_free won't free it */
}
if (ssh_version == 2 && priv->encrypted_key_file &&
!priv_in_tree->encrypted_key_file) {
/* Conversely, the key was only stored in clear, and now
* we have an encrypted version to add to it. */
priv_in_tree->encrypted_key_file = priv->encrypted_key_file;
priv->encrypted_key_file = NULL;
priv_in_tree->encrypted_key_comment = priv->encrypted_key_comment;
priv->encrypted_key_comment = NULL;
}
pk_priv_free(priv);
}
/*
* Try to add the public key.
*/
PageantPublicKey *pub_in_tree = add234(pubkeytree, pub);
if (pub_in_tree == pub) {
/* Successfully added a new key. */
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
return true;
} else {
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
/* This public key was already there. */
pk_pub_free(pub);
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
return false;
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
}
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
static bool pageant_add_ssh1_key(RSAKey *rkey)
{
PageantPublicKey *pub = snew(PageantPublicKey);
memset(pub, 0, sizeof(PageantPublicKey));
PageantPrivateKey *priv = snew(PageantPrivateKey);
memset(priv, 0, sizeof(PageantPrivateKey));
priv->sort.ssh_version = 1;
priv->base_pub = makeblob1(rkey);
pub->full_pub = makeblob1(rkey);
if (rkey->comment)
pub->comment = dupstr(rkey->comment);
priv->rkey = snew(RSAKey);
duprsakey(priv->rkey, rkey);
return pageant_add_key_common(pub, priv);
}
Make unused Pageant accessor functions private. We're no longer calling pageant_nth_ssh*_key or pageant_add_ssh*_key from outside pageant.c. Remove them from pageant.h and turn them static, so that we carry on not doing so.
2021-04-02 10:39:01 +00:00
static bool pageant_add_ssh2_key(ssh2_userkey *skey)
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub = snew(PageantPublicKey);
memset(pub, 0, sizeof(PageantPublicKey));
PageantPrivateKey *priv = snew(PageantPrivateKey);
memset(priv, 0, sizeof(PageantPrivateKey));
priv->sort.ssh_version = 2;
priv->base_pub = makeblob2base(skey->key);
pub->full_pub = makeblob2full(skey->key);
if (skey->comment)
pub->comment = dupstr(skey->comment);
/* Duplicate the ssh_key to go in priv */
{
strbuf *tmp = strbuf_new_nm();
ssh_key_openssh_blob(skey->key, BinarySink_UPCAST(tmp));
BinarySource src[1];
BinarySource_BARE_INIT_PL(src, ptrlen_from_strbuf(tmp));
priv->skey = ssh_key_new_priv_openssh(ssh_key_alg(skey->key), src);
strbuf_free(tmp);
}
return pageant_add_key_common(pub, priv);
}
static bool pageant_add_ssh2_key_encrypted(PageantPublicKeySort sort,
const char *comment, ptrlen keyfile)
{
PageantPublicKey *pub = snew(PageantPublicKey);
memset(pub, 0, sizeof(PageantPublicKey));
PageantPrivateKey *priv = snew(PageantPrivateKey);
memset(priv, 0, sizeof(PageantPrivateKey));
assert(sort.priv.ssh_version == 2);
priv->sort.ssh_version = sort.priv.ssh_version;
priv->base_pub = strbuf_dup(sort.priv.base_pub);
pub->full_pub = strbuf_dup(sort.full_pub);
pub->comment = dupstr(comment);
priv->encrypted_key_file = strbuf_dup_nm(keyfile);
priv->encrypted_key_comment = dupstr(comment);
return pageant_add_key_common(pub, priv);
}
static void remove_pubkey_cleanup(PageantPublicKey *pub)
{
/* Common function called when we've just removed a public key
* from pubkeytree: we must also check whether that was the last
* public key sharing a private half, and if so, remove the
* corresponding private entry too. */
PageantPublicKeySort pubsearch;
pubsearch.priv = pub->sort.priv;
pubsearch.full_pub = PTRLEN_LITERAL("");
PageantPublicKey *pubfound = findrel234(
pubkeytree, &pubsearch, NULL, REL234_GE);
if (pubfound && !privkey_cmpfn(&pub->sort.priv, &pubfound->sort.priv)) {
/* There's still a public key which has the same sort.priv as
* the one we've just removed. We're good. */
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
} else {
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
/* We've just removed the last public key of the family, so
* delete the private half as well. */
PageantPrivateKey *priv = del234(privkeytree, &pub->sort.priv);
assert(priv);
assert(!privkey_cmpfn(&priv->sort, &pub->sort.priv));
pk_priv_free(priv);
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
}
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
static PageantPublicKey *del_pubkey_pos(int pos)
{
PageantPublicKey *deleted = delpos234(pubkeytree, pos);
remove_pubkey_cleanup(deleted);
return deleted;
}
static void del_pubkey(PageantPublicKey *to_delete)
{
PageantPublicKey *deleted = del234(pubkeytree, to_delete);
remove_pubkey_cleanup(deleted);
}
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
static void remove_all_keys(int ssh_version)
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
int start = find_first_pubkey_for_version(ssh_version);
int end = find_first_pubkey_for_version(ssh_version + 1);
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
while (end > start) {
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub = del_pubkey_pos(--end);
assert(pub->sort.priv.ssh_version == ssh_version);
pk_pub_free(pub);
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
}
}
Pageant: new PuTTY-specific ext request, 'list-extended'. This is an extended version of SSH2_AGENTC_REQUEST_IDENTITIES, which augments each entry in the returned key list with an extra field containing additional data about the key. The initial contents of that extra field are a pair of flags indicating whether the key is currently stored in the agent encrypted, decrypted or both. The idea is that this will permit a Pageant-aware client to make decisions based on that. For a start, the output key list can mention it to the user; also, if you try to add a key unencrypted when it's already present, we can discriminate based on whether it's already present _unencrypted_
2020-12-15 13:25:45 +00:00
static void list_keys(BinarySink *bs, int ssh_version, bool extended)
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
{
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
int i;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub;
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
put_uint32(bs, count_keys(ssh_version));
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
for (i = find_first_pubkey_for_version(ssh_version);
NULL != (pub = index234(pubkeytree, i)); i++) {
if (pub->sort.priv.ssh_version != ssh_version)
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
break;
if (ssh_version > 1)
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
put_stringpl(bs, pub->sort.full_pub);
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
else
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
put_datapl(bs, pub->sort.full_pub); /* no header */
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
put_stringpl(bs, ptrlen_from_asciz(pub->comment));
Pageant: new PuTTY-specific ext request, 'list-extended'. This is an extended version of SSH2_AGENTC_REQUEST_IDENTITIES, which augments each entry in the returned key list with an extra field containing additional data about the key. The initial contents of that extra field are a pair of flags indicating whether the key is currently stored in the agent encrypted, decrypted or both. The idea is that this will permit a Pageant-aware client to make decisions based on that. For a start, the output key list can mention it to the user; also, if you try to add a key unencrypted when it's already present, we can discriminate based on whether it's already present _unencrypted_
2020-12-15 13:25:45 +00:00
if (extended) {
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
assert(ssh_version == 2); /* extended lists not supported in v1 */
Pageant: new PuTTY-specific ext request, 'list-extended'. This is an extended version of SSH2_AGENTC_REQUEST_IDENTITIES, which augments each entry in the returned key list with an extra field containing additional data about the key. The initial contents of that extra field are a pair of flags indicating whether the key is currently stored in the agent encrypted, decrypted or both. The idea is that this will permit a Pageant-aware client to make decisions based on that. For a start, the output key list can mention it to the user; also, if you try to add a key unencrypted when it's already present, we can discriminate based on whether it's already present _unencrypted_
2020-12-15 13:25:45 +00:00
/*
* Append to each key entry a string containing extension
* data. This string begins with a flags word, and may in
* future contain further data if flag bits are set saying
* that it does. Hence, it's wrapped in a containing
* string, so that clients that only partially understand
* it can still find the parts they do understand.
*/
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPrivateKey *priv = pub_to_priv(pub);
Pageant: new PuTTY-specific ext request, 'list-extended'. This is an extended version of SSH2_AGENTC_REQUEST_IDENTITIES, which augments each entry in the returned key list with an extra field containing additional data about the key. The initial contents of that extra field are a pair of flags indicating whether the key is currently stored in the agent encrypted, decrypted or both. The idea is that this will permit a Pageant-aware client to make decisions based on that. For a start, the output key list can mention it to the user; also, if you try to add a key unencrypted when it's already present, we can discriminate based on whether it's already present _unencrypted_
2020-12-15 13:25:45 +00:00
strbuf *sb = strbuf_new();
uint32_t flags = 0;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (!priv->skey)
Pageant: new PuTTY-specific ext request, 'list-extended'. This is an extended version of SSH2_AGENTC_REQUEST_IDENTITIES, which augments each entry in the returned key list with an extra field containing additional data about the key. The initial contents of that extra field are a pair of flags indicating whether the key is currently stored in the agent encrypted, decrypted or both. The idea is that this will permit a Pageant-aware client to make decisions based on that. For a start, the output key list can mention it to the user; also, if you try to add a key unencrypted when it's already present, we can discriminate based on whether it's already present _unencrypted_
2020-12-15 13:25:45 +00:00
flags |= LIST_EXTENDED_FLAG_HAS_NO_CLEARTEXT_KEY;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (priv->encrypted_key_file)
Pageant: new PuTTY-specific ext request, 'list-extended'. This is an extended version of SSH2_AGENTC_REQUEST_IDENTITIES, which augments each entry in the returned key list with an extra field containing additional data about the key. The initial contents of that extra field are a pair of flags indicating whether the key is currently stored in the agent encrypted, decrypted or both. The idea is that this will permit a Pageant-aware client to make decisions based on that. For a start, the output key list can mention it to the user; also, if you try to add a key unencrypted when it's already present, we can discriminate based on whether it's already present _unencrypted_
2020-12-15 13:25:45 +00:00
flags |= LIST_EXTENDED_FLAG_HAS_ENCRYPTED_KEY_FILE;
put_uint32(sb, flags);
put_stringsb(bs, sb);
}
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
}
}
Pageant: new PuTTY-specific ext request, 'list-extended'. This is an extended version of SSH2_AGENTC_REQUEST_IDENTITIES, which augments each entry in the returned key list with an extra field containing additional data about the key. The initial contents of that extra field are a pair of flags indicating whether the key is currently stored in the agent encrypted, decrypted or both. The idea is that this will permit a Pageant-aware client to make decisions based on that. For a start, the output key list can mention it to the user; also, if you try to add a key unencrypted when it's already present, we can discriminate based on whether it's already present _unencrypted_
2020-12-15 13:25:45 +00:00
void pageant_make_keylist1(BinarySink *bs) { list_keys(bs, 1, false); }
void pageant_make_keylist2(BinarySink *bs) { list_keys(bs, 2, false); }
void pageant_make_keylist_extended(BinarySink *bs) { list_keys(bs, 2, true); }
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +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
void pageant_register_client(PageantClient *pc)
{
pc->info = snew(PageantClientInfo);
pc->info->pc = pc;
pc->info->head.prev = pc->info->head.next = &pc->info->head;
}
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
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
void pageant_unregister_client(PageantClient *pc)
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
{
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
PageantClientInfo *info = pc->info;
assert(info);
assert(info->pc == pc);
while (pc->info->head.next != &pc->info->head) {
PageantAsyncOp *pao = container_of(pc->info->head.next,
PageantAsyncOp, cr);
pageant_async_op_unlink_and_free(pao);
}
sfree(pc->info);
}
Pageant: handle agent extension messages more correctly. Reading draft-miller-ssh-agent-04 more carefully, I see that I missed a few things from the extension-message spec. Firstly, there's an extension request "query" which is supposed to list all the extensions you support. Secondly, if you recognise an extension-request name but are then unable to fulfill the request for some other reason, you're supposed to return a new kind of failure message that's distinct from SSH_AGENT_FAILURE, because for extensions, the latter is reserved for "I don't even know what this extension name means at all". I've fixed both of those bugs in Pageant by making a centralised map of known extension names to an enumeration of internal ids, and an array containing the name for each id. So we can reliably answer the "query" extension by iterating over that array, and also use the same array to recognise known extensions up front and give them centralised processing (in particular, resetting the failure-message type) before switching on the particular extension index.
2020-02-10 20:45:31 +00:00
static PRINTF_LIKE(5, 6) void failure(
PageantClient *pc, PageantClientRequestId *reqid, strbuf *sb,
unsigned char type, const char *fmt, ...)
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
{
strbuf_clear(sb);
Pageant: handle agent extension messages more correctly. Reading draft-miller-ssh-agent-04 more carefully, I see that I missed a few things from the extension-message spec. Firstly, there's an extension request "query" which is supposed to list all the extensions you support. Secondly, if you recognise an extension-request name but are then unable to fulfill the request for some other reason, you're supposed to return a new kind of failure message that's distinct from SSH_AGENT_FAILURE, because for extensions, the latter is reserved for "I don't even know what this extension name means at all". I've fixed both of those bugs in Pageant by making a centralised map of known extension names to an enumeration of internal ids, and an array containing the name for each id. So we can reliably answer the "query" extension by iterating over that array, and also use the same array to recognise known extensions up front and give them centralised processing (in particular, resetting the failure-message type) before switching on the particular extension index.
2020-02-10 20:45:31 +00:00
put_byte(sb, type);
Pageant: new asynchronous internal APIs. This is a pure refactoring: no functional change expected. This commit introduces two new small vtable-style APIs. One is PageantClient, which identifies a particular client of the Pageant 'core' (meaning the code that handles each individual request). This changes pageant_handle_msg into an asynchronous operation: you pass in an agent request message and an identifier, and at some later point, the got_response method in your PageantClient will be called with the answer (and the same identifier, to allow you to match requests to responses). The trait vtable also contains a logging system. The main importance of PageantClient, and the reason why it has to exist instead of just passing pageant_handle_msg a bare callback function pointer and context parameter, is that it provides robustness if a client stops existing while a request is still pending. You call pageant_unregister_client, and any unfinished requests associated with that client in the Pageant core will be cleaned up, so that you're guaranteed that after the unregister operation, no stray callbacks will happen with a stale pointer to that client. The WM_COPYDATA interface of Windows Pageant is a direct client of this API. The other client is PageantListener, the system that lives in pageant.c and handles stream-based agent connections for both Unix Pageant and the new Windows named-pipe IPC. More specifically, each individual connection to the listening socket is a separate PageantClient, which means that if a socket is closed abruptly or suffers an OS error, that client can be unregistered and any pending requests cancelled without disrupting other connections. Users of PageantListener have a second client vtable they can use, called PageantListenerClient. That contains _only_ logging facilities, and at the moment, only Unix Pageant bothers to use it (and even that only in debugging mode). Finally, internally to the Pageant core, there's a new trait called PageantAsyncOp which describes an agent request in the process of being handled. But at the moment, it has only one trivial implementation, which is handed the full response message already constructed, and on the next toplevel callback, passes it back to the PageantClient.
2020-01-25 17:24:28 +00:00
if (!pc->suppress_logging) {
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
va_list ap;
va_start(ap, fmt);
Pageant: fix dupprintf/dupvprintf error. This mistake was introduced very recently, in commit de38a4d82..
2020-01-29 06:13:41 +00:00
char *msg = dupvprintf(fmt, ap);
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
va_end(ap);
Pageant: new asynchronous internal APIs. This is a pure refactoring: no functional change expected. This commit introduces two new small vtable-style APIs. One is PageantClient, which identifies a particular client of the Pageant 'core' (meaning the code that handles each individual request). This changes pageant_handle_msg into an asynchronous operation: you pass in an agent request message and an identifier, and at some later point, the got_response method in your PageantClient will be called with the answer (and the same identifier, to allow you to match requests to responses). The trait vtable also contains a logging system. The main importance of PageantClient, and the reason why it has to exist instead of just passing pageant_handle_msg a bare callback function pointer and context parameter, is that it provides robustness if a client stops existing while a request is still pending. You call pageant_unregister_client, and any unfinished requests associated with that client in the Pageant core will be cleaned up, so that you're guaranteed that after the unregister operation, no stray callbacks will happen with a stale pointer to that client. The WM_COPYDATA interface of Windows Pageant is a direct client of this API. The other client is PageantListener, the system that lives in pageant.c and handles stream-based agent connections for both Unix Pageant and the new Windows named-pipe IPC. More specifically, each individual connection to the listening socket is a separate PageantClient, which means that if a socket is closed abruptly or suffers an OS error, that client can be unregistered and any pending requests cancelled without disrupting other connections. Users of PageantListener have a second client vtable they can use, called PageantListenerClient. That contains _only_ logging facilities, and at the moment, only Unix Pageant bothers to use it (and even that only in debugging mode). Finally, internally to the Pageant core, there's a new trait called PageantAsyncOp which describes an agent request in the process of being handled. But at the moment, it has only one trivial implementation, which is handed the full response message already constructed, and on the next toplevel callback, passes it back to the PageantClient.
2020-01-25 17:24:28 +00:00
pageant_client_log(pc, reqid, "reply: SSH_AGENT_FAILURE (%s)", msg);
sfree(msg);
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
}
}
Pageant: fix concurrent attempts to use an encrypted key. If you had a key stored encrypted in Pageant, and you launched two PuTTY sessions both trying to generate a signature with the key, and then didn't type the passphrase into the async passphrase prompt until after both sessions had made requests, then only one of the requests would be replied to once you decrypted the key. The other would sit there waiting for a response that Pageant never got round to sending. This would also happen in the case where you launched two PuTTY sessions each trying to use a _different_ encrypted key in Pageant, in which case Pageant should have presented the next GUI passphrase box after the first one was dismissed. That didn't happen either. This was the result of two separate bugs in the code. Firstly, when signop_coroutine() noticed that a GUI request was already in progress, it would crReturn without making any arrangement to be called back. Now there's a queue of 'requests blocked on waiting for some GUI prompt to finish'. Secondly, if multiple requests were blocked on the same key, the code that went over the linked list of them had a bug in which it would unblock the _first_ list item in every iteration, instead of unblocking all the items once each.
2022-06-11 11:46:29 +00:00
static void signop_link_to_key(PageantSignOp *so)
Pageant: fix misuse of the blocked_requests queue. A PageantSignOp for a not-yet-decrypted key was being linked on to its key's blocked_requests queue twice, mangling the linked list integrity and causing segfaults. Now we take care to NULL out the pointers within the signop to indicate that it isn't currently on the queue, and check whether it's currently linked before linking or unlinking it.
2020-02-11 19:11:10 +00:00
{
assert(!so->pkr.prev);
assert(!so->pkr.next);
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
so->pkr.prev = so->priv->blocked_requests.prev;
so->pkr.next = &so->priv->blocked_requests;
Pageant: fix misuse of the blocked_requests queue. A PageantSignOp for a not-yet-decrypted key was being linked on to its key's blocked_requests queue twice, mangling the linked list integrity and causing segfaults. Now we take care to NULL out the pointers within the signop to indicate that it isn't currently on the queue, and check whether it's currently linked before linking or unlinking it.
2020-02-11 19:11:10 +00:00
so->pkr.prev->next = &so->pkr;
so->pkr.next->prev = &so->pkr;
}
Pageant: fix concurrent attempts to use an encrypted key. If you had a key stored encrypted in Pageant, and you launched two PuTTY sessions both trying to generate a signature with the key, and then didn't type the passphrase into the async passphrase prompt until after both sessions had made requests, then only one of the requests would be replied to once you decrypted the key. The other would sit there waiting for a response that Pageant never got round to sending. This would also happen in the case where you launched two PuTTY sessions each trying to use a _different_ encrypted key in Pageant, in which case Pageant should have presented the next GUI passphrase box after the first one was dismissed. That didn't happen either. This was the result of two separate bugs in the code. Firstly, when signop_coroutine() noticed that a GUI request was already in progress, it would crReturn without making any arrangement to be called back. Now there's a queue of 'requests blocked on waiting for some GUI prompt to finish'. Secondly, if multiple requests were blocked on the same key, the code that went over the linked list of them had a bug in which it would unblock the _first_ list item in every iteration, instead of unblocking all the items once each.
2022-06-11 11:46:29 +00:00
static void signop_link_to_pending_gui_request(PageantSignOp *so)
{
assert(!so->pkr.prev);
assert(!so->pkr.next);
so->pkr.prev = requests_blocked_on_gui.prev;
so->pkr.next = &requests_blocked_on_gui;
so->pkr.prev->next = &so->pkr;
so->pkr.next->prev = &so->pkr;
}
Pageant: fix misuse of the blocked_requests queue. A PageantSignOp for a not-yet-decrypted key was being linked on to its key's blocked_requests queue twice, mangling the linked list integrity and causing segfaults. Now we take care to NULL out the pointers within the signop to indicate that it isn't currently on the queue, and check whether it's currently linked before linking or unlinking it.
2020-02-11 19:11:10 +00:00
static void signop_unlink(PageantSignOp *so)
{
if (so->pkr.next) {
assert(so->pkr.prev);
so->pkr.next->prev = so->pkr.prev;
so->pkr.prev->next = so->pkr.next;
Pageant: fix concurrent attempts to use an encrypted key. If you had a key stored encrypted in Pageant, and you launched two PuTTY sessions both trying to generate a signature with the key, and then didn't type the passphrase into the async passphrase prompt until after both sessions had made requests, then only one of the requests would be replied to once you decrypted the key. The other would sit there waiting for a response that Pageant never got round to sending. This would also happen in the case where you launched two PuTTY sessions each trying to use a _different_ encrypted key in Pageant, in which case Pageant should have presented the next GUI passphrase box after the first one was dismissed. That didn't happen either. This was the result of two separate bugs in the code. Firstly, when signop_coroutine() noticed that a GUI request was already in progress, it would crReturn without making any arrangement to be called back. Now there's a queue of 'requests blocked on waiting for some GUI prompt to finish'. Secondly, if multiple requests were blocked on the same key, the code that went over the linked list of them had a bug in which it would unblock the _first_ list item in every iteration, instead of unblocking all the items once each.
2022-06-11 11:46:29 +00:00
so->pkr.prev = so->pkr.next = NULL;
Pageant: fix misuse of the blocked_requests queue. A PageantSignOp for a not-yet-decrypted key was being linked on to its key's blocked_requests queue twice, mangling the linked list integrity and causing segfaults. Now we take care to NULL out the pointers within the signop to indicate that it isn't currently on the queue, and check whether it's currently linked before linking or unlinking it.
2020-02-11 19:11:10 +00:00
} else {
assert(!so->pkr.prev);
}
}
Pageant: move signing requests out into a coroutine. The previous commit introduced the PageantAsyncOp trait, with only one trivial implementation. This one introduces a second implementation used for SSH2_AGENTC_SIGN_REQUEST only, which waits to actually construct the signature until after a callback has happened. This will allow the signing process to be suspended in order to request a dialog box and wait for a user response to decide _how_ to reply. Suspended signing operations relating to a particular key are held in a linked list dangling from the corresponding PageantKey structure. This will allow them all to be found easily if that key should be deleted from the agent: in that situation pending signatures from the key will all return SSH_AGENT_FAILURE. Still no functional change, however: the new coroutine doesn't actually wait for anything, it just contains a comment noting that it could if it wanted to.
2020-01-25 17:25:28 +00:00
static void signop_free(PageantAsyncOp *pao)
{
PageantSignOp *so = container_of(pao, PageantSignOp, pao);
strbuf_free(so->data_to_sign);
sfree(so);
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
static bool request_passphrase(PageantClient *pc, PageantPrivateKey *priv)
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (!priv->decryption_prompt_active) {
Make the Pageant core serialise GUI requests.
2020-02-08 18:08:20 +00:00
assert(!gui_request_in_progress);
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
bool created_dlg = pageant_client_ask_passphrase(
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
pc, &priv->dlgid, priv->encrypted_key_comment);
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
if (!created_dlg)
return false;
Make the Pageant core serialise GUI requests.
2020-02-08 18:08:20 +00:00
gui_request_in_progress = true;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
priv->decryption_prompt_active = true;
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
}
return true;
}
Pageant: move signing requests out into a coroutine. The previous commit introduced the PageantAsyncOp trait, with only one trivial implementation. This one introduces a second implementation used for SSH2_AGENTC_SIGN_REQUEST only, which waits to actually construct the signature until after a callback has happened. This will allow the signing process to be suspended in order to request a dialog box and wait for a user response to decide _how_ to reply. Suspended signing operations relating to a particular key are held in a linked list dangling from the corresponding PageantKey structure. This will allow them all to be found easily if that key should be deleted from the agent: in that situation pending signatures from the key will all return SSH_AGENT_FAILURE. Still no functional change, however: the new coroutine doesn't actually wait for anything, it just contains a comment noting that it could if it wanted to.
2020-01-25 17:25:28 +00:00
static void signop_coroutine(PageantAsyncOp *pao)
{
PageantSignOp *so = container_of(pao, PageantSignOp, pao);
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
strbuf *response;
Pageant: move signing requests out into a coroutine. The previous commit introduced the PageantAsyncOp trait, with only one trivial implementation. This one introduces a second implementation used for SSH2_AGENTC_SIGN_REQUEST only, which waits to actually construct the signature until after a callback has happened. This will allow the signing process to be suspended in order to request a dialog box and wait for a user response to decide _how_ to reply. Suspended signing operations relating to a particular key are held in a linked list dangling from the corresponding PageantKey structure. This will allow them all to be found easily if that key should be deleted from the agent: in that situation pending signatures from the key will all return SSH_AGENT_FAILURE. Still no functional change, however: the new coroutine doesn't actually wait for anything, it just contains a comment noting that it could if it wanted to.
2020-01-25 17:25:28 +00:00
crBegin(so->crLine);
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
while (!so->priv->skey && gui_request_in_progress) {
Pageant: fix concurrent attempts to use an encrypted key. If you had a key stored encrypted in Pageant, and you launched two PuTTY sessions both trying to generate a signature with the key, and then didn't type the passphrase into the async passphrase prompt until after both sessions had made requests, then only one of the requests would be replied to once you decrypted the key. The other would sit there waiting for a response that Pageant never got round to sending. This would also happen in the case where you launched two PuTTY sessions each trying to use a _different_ encrypted key in Pageant, in which case Pageant should have presented the next GUI passphrase box after the first one was dismissed. That didn't happen either. This was the result of two separate bugs in the code. Firstly, when signop_coroutine() noticed that a GUI request was already in progress, it would crReturn without making any arrangement to be called back. Now there's a queue of 'requests blocked on waiting for some GUI prompt to finish'. Secondly, if multiple requests were blocked on the same key, the code that went over the linked list of them had a bug in which it would unblock the _first_ list item in every iteration, instead of unblocking all the items once each.
2022-06-11 11:46:29 +00:00
signop_link_to_pending_gui_request(so);
Make the Pageant core serialise GUI requests.
2020-02-08 18:08:20 +00:00
crReturnV;
Pageant: fix concurrent attempts to use an encrypted key. If you had a key stored encrypted in Pageant, and you launched two PuTTY sessions both trying to generate a signature with the key, and then didn't type the passphrase into the async passphrase prompt until after both sessions had made requests, then only one of the requests would be replied to once you decrypted the key. The other would sit there waiting for a response that Pageant never got round to sending. This would also happen in the case where you launched two PuTTY sessions each trying to use a _different_ encrypted key in Pageant, in which case Pageant should have presented the next GUI passphrase box after the first one was dismissed. That didn't happen either. This was the result of two separate bugs in the code. Firstly, when signop_coroutine() noticed that a GUI request was already in progress, it would crReturn without making any arrangement to be called back. Now there's a queue of 'requests blocked on waiting for some GUI prompt to finish'. Secondly, if multiple requests were blocked on the same key, the code that went over the linked list of them had a bug in which it would unblock the _first_ list item in every iteration, instead of unblocking all the items once each.
2022-06-11 11:46:29 +00:00
signop_unlink(so);
}
Make the Pageant core serialise GUI requests.
2020-02-08 18:08:20 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (!so->priv->skey) {
assert(so->priv->encrypted_key_file);
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (!request_passphrase(so->pao.info->pc, so->priv)) {
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
response = strbuf_new();
failure(so->pao.info->pc, so->pao.reqid, response,
Pageant: handle agent extension messages more correctly. Reading draft-miller-ssh-agent-04 more carefully, I see that I missed a few things from the extension-message spec. Firstly, there's an extension request "query" which is supposed to list all the extensions you support. Secondly, if you recognise an extension-request name but are then unable to fulfill the request for some other reason, you're supposed to return a new kind of failure message that's distinct from SSH_AGENT_FAILURE, because for extensions, the latter is reserved for "I don't even know what this extension name means at all". I've fixed both of those bugs in Pageant by making a centralised map of known extension names to an enumeration of internal ids, and an array containing the name for each id. So we can reliably answer the "query" extension by iterating over that array, and also use the same array to recognise known extensions up front and give them centralised processing (in particular, resetting the failure-message type) before switching on the particular extension index.
2020-02-10 20:45:31 +00:00
so->failure_type, "on-demand decryption could not "
"prompt for a passphrase");
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
goto respond;
}
Pageant: fix concurrent attempts to use an encrypted key. If you had a key stored encrypted in Pageant, and you launched two PuTTY sessions both trying to generate a signature with the key, and then didn't type the passphrase into the async passphrase prompt until after both sessions had made requests, then only one of the requests would be replied to once you decrypted the key. The other would sit there waiting for a response that Pageant never got round to sending. This would also happen in the case where you launched two PuTTY sessions each trying to use a _different_ encrypted key in Pageant, in which case Pageant should have presented the next GUI passphrase box after the first one was dismissed. That didn't happen either. This was the result of two separate bugs in the code. Firstly, when signop_coroutine() noticed that a GUI request was already in progress, it would crReturn without making any arrangement to be called back. Now there's a queue of 'requests blocked on waiting for some GUI prompt to finish'. Secondly, if multiple requests were blocked on the same key, the code that went over the linked list of them had a bug in which it would unblock the _first_ list item in every iteration, instead of unblocking all the items once each.
2022-06-11 11:46:29 +00:00
signop_link_to_key(so);
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
crReturnV;
Pageant: fix misuse of the blocked_requests queue. A PageantSignOp for a not-yet-decrypted key was being linked on to its key's blocked_requests queue twice, mangling the linked list integrity and causing segfaults. Now we take care to NULL out the pointers within the signop to indicate that it isn't currently on the queue, and check whether it's currently linked before linking or unlinking it.
2020-02-11 19:11:10 +00:00
signop_unlink(so);
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
uint32_t supported_flags = ssh_key_supported_flags(so->priv->skey);
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
if (so->flags & ~supported_flags) {
/*
* We MUST reject any message containing flags we don't
* understand.
*/
response = strbuf_new();
Pageant: handle agent extension messages more correctly. Reading draft-miller-ssh-agent-04 more carefully, I see that I missed a few things from the extension-message spec. Firstly, there's an extension request "query" which is supposed to list all the extensions you support. Secondly, if you recognise an extension-request name but are then unable to fulfill the request for some other reason, you're supposed to return a new kind of failure message that's distinct from SSH_AGENT_FAILURE, because for extensions, the latter is reserved for "I don't even know what this extension name means at all". I've fixed both of those bugs in Pageant by making a centralised map of known extension names to an enumeration of internal ids, and an array containing the name for each id. So we can reliably answer the "query" extension by iterating over that array, and also use the same array to recognise known extensions up front and give them centralised processing (in particular, resetting the failure-message type) before switching on the particular extension index.
2020-02-10 20:45:31 +00:00
failure(so->pao.info->pc, so->pao.reqid, response, so->failure_type,
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
"unsupported flag bits 0x%08"PRIx32,
so->flags & ~supported_flags);
goto respond;
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
char *invalid = ssh_key_invalid(so->priv->skey, so->flags);
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
if (invalid) {
response = strbuf_new();
Pageant: handle agent extension messages more correctly. Reading draft-miller-ssh-agent-04 more carefully, I see that I missed a few things from the extension-message spec. Firstly, there's an extension request "query" which is supposed to list all the extensions you support. Secondly, if you recognise an extension-request name but are then unable to fulfill the request for some other reason, you're supposed to return a new kind of failure message that's distinct from SSH_AGENT_FAILURE, because for extensions, the latter is reserved for "I don't even know what this extension name means at all". I've fixed both of those bugs in Pageant by making a centralised map of known extension names to an enumeration of internal ids, and an array containing the name for each id. So we can reliably answer the "query" extension by iterating over that array, and also use the same array to recognise known extensions up front and give them centralised processing (in particular, resetting the failure-message type) before switching on the particular extension index.
2020-02-10 20:45:31 +00:00
failure(so->pao.info->pc, so->pao.reqid, response, so->failure_type,
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
"key invalid: %s", invalid);
sfree(invalid);
goto respond;
}
Pageant: move signing requests out into a coroutine. The previous commit introduced the PageantAsyncOp trait, with only one trivial implementation. This one introduces a second implementation used for SSH2_AGENTC_SIGN_REQUEST only, which waits to actually construct the signature until after a callback has happened. This will allow the signing process to be suspended in order to request a dialog box and wait for a user response to decide _how_ to reply. Suspended signing operations relating to a particular key are held in a linked list dangling from the corresponding PageantKey structure. This will allow them all to be found easily if that key should be deleted from the agent: in that situation pending signatures from the key will all return SSH_AGENT_FAILURE. Still no functional change, however: the new coroutine doesn't actually wait for anything, it just contains a comment noting that it could if it wanted to.
2020-01-25 17:25:28 +00:00
strbuf *signature = strbuf_new();
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
ssh_key_sign(so->priv->skey, ptrlen_from_strbuf(so->data_to_sign),
Pageant: move signing requests out into a coroutine. The previous commit introduced the PageantAsyncOp trait, with only one trivial implementation. This one introduces a second implementation used for SSH2_AGENTC_SIGN_REQUEST only, which waits to actually construct the signature until after a callback has happened. This will allow the signing process to be suspended in order to request a dialog box and wait for a user response to decide _how_ to reply. Suspended signing operations relating to a particular key are held in a linked list dangling from the corresponding PageantKey structure. This will allow them all to be found easily if that key should be deleted from the agent: in that situation pending signatures from the key will all return SSH_AGENT_FAILURE. Still no functional change, however: the new coroutine doesn't actually wait for anything, it just contains a comment noting that it could if it wanted to.
2020-01-25 17:25:28 +00:00
so->flags, BinarySink_UPCAST(signature));
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
response = strbuf_new();
Pageant: move signing requests out into a coroutine. The previous commit introduced the PageantAsyncOp trait, with only one trivial implementation. This one introduces a second implementation used for SSH2_AGENTC_SIGN_REQUEST only, which waits to actually construct the signature until after a callback has happened. This will allow the signing process to be suspended in order to request a dialog box and wait for a user response to decide _how_ to reply. Suspended signing operations relating to a particular key are held in a linked list dangling from the corresponding PageantKey structure. This will allow them all to be found easily if that key should be deleted from the agent: in that situation pending signatures from the key will all return SSH_AGENT_FAILURE. Still no functional change, however: the new coroutine doesn't actually wait for anything, it just contains a comment noting that it could if it wanted to.
2020-01-25 17:25:28 +00:00
put_byte(response, SSH2_AGENT_SIGN_RESPONSE);
put_stringsb(response, signature);
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
respond:
Pageant: move signing requests out into a coroutine. The previous commit introduced the PageantAsyncOp trait, with only one trivial implementation. This one introduces a second implementation used for SSH2_AGENTC_SIGN_REQUEST only, which waits to actually construct the signature until after a callback has happened. This will allow the signing process to be suspended in order to request a dialog box and wait for a user response to decide _how_ to reply. Suspended signing operations relating to a particular key are held in a linked list dangling from the corresponding PageantKey structure. This will allow them all to be found easily if that key should be deleted from the agent: in that situation pending signatures from the key will all return SSH_AGENT_FAILURE. Still no functional change, however: the new coroutine doesn't actually wait for anything, it just contains a comment noting that it could if it wanted to.
2020-01-25 17:25:28 +00:00
pageant_client_got_response(so->pao.info->pc, so->pao.reqid,
ptrlen_from_strbuf(response));
strbuf_free(response);
pageant_async_op_unlink_and_free(&so->pao);
crFinishFreedV;
}
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
static const PageantAsyncOpVtable signop_vtable = {
.coroutine = signop_coroutine,
.free = signop_free,
Pageant: move signing requests out into a coroutine. The previous commit introduced the PageantAsyncOp trait, with only one trivial implementation. This one introduces a second implementation used for SSH2_AGENTC_SIGN_REQUEST only, which waits to actually construct the signature until after a callback has happened. This will allow the signing process to be suspended in order to request a dialog box and wait for a user response to decide _how_ to reply. Suspended signing operations relating to a particular key are held in a linked list dangling from the corresponding PageantKey structure. This will allow them all to be found easily if that key should be deleted from the agent: in that situation pending signatures from the key will all return SSH_AGENT_FAILURE. Still no functional change, however: the new coroutine doesn't actually wait for anything, it just contains a comment noting that it could if it wanted to.
2020-01-25 17:25:28 +00:00
};
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
static void fail_requests_for_key(PageantPrivateKey *priv, const char *reason)
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
while (priv->blocked_requests.next != &priv->blocked_requests) {
PageantSignOp *so = container_of(priv->blocked_requests.next,
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
PageantSignOp, pkr);
Pageant: fix misuse of the blocked_requests queue. A PageantSignOp for a not-yet-decrypted key was being linked on to its key's blocked_requests queue twice, mangling the linked list integrity and causing segfaults. Now we take care to NULL out the pointers within the signop to indicate that it isn't currently on the queue, and check whether it's currently linked before linking or unlinking it.
2020-02-11 19:11:10 +00:00
signop_unlink(so);
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
strbuf *sb = strbuf_new();
Pageant: handle agent extension messages more correctly. Reading draft-miller-ssh-agent-04 more carefully, I see that I missed a few things from the extension-message spec. Firstly, there's an extension request "query" which is supposed to list all the extensions you support. Secondly, if you recognise an extension-request name but are then unable to fulfill the request for some other reason, you're supposed to return a new kind of failure message that's distinct from SSH_AGENT_FAILURE, because for extensions, the latter is reserved for "I don't even know what this extension name means at all". I've fixed both of those bugs in Pageant by making a centralised map of known extension names to an enumeration of internal ids, and an array containing the name for each id. So we can reliably answer the "query" extension by iterating over that array, and also use the same array to recognise known extensions up front and give them centralised processing (in particular, resetting the failure-message type) before switching on the particular extension index.
2020-02-10 20:45:31 +00:00
failure(so->pao.info->pc, so->pao.reqid, sb, so->failure_type,
"%s", reason);
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
pageant_client_got_response(so->pao.info->pc, so->pao.reqid,
ptrlen_from_strbuf(sb));
strbuf_free(sb);
pageant_async_op_unlink_and_free(&so->pao);
}
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
static void unblock_requests_for_key(PageantPrivateKey *priv)
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
for (PageantKeyRequestNode *pkr = priv->blocked_requests.next;
pkr != &priv->blocked_requests; pkr = pkr->next) {
Pageant: fix concurrent attempts to use an encrypted key. If you had a key stored encrypted in Pageant, and you launched two PuTTY sessions both trying to generate a signature with the key, and then didn't type the passphrase into the async passphrase prompt until after both sessions had made requests, then only one of the requests would be replied to once you decrypted the key. The other would sit there waiting for a response that Pageant never got round to sending. This would also happen in the case where you launched two PuTTY sessions each trying to use a _different_ encrypted key in Pageant, in which case Pageant should have presented the next GUI passphrase box after the first one was dismissed. That didn't happen either. This was the result of two separate bugs in the code. Firstly, when signop_coroutine() noticed that a GUI request was already in progress, it would crReturn without making any arrangement to be called back. Now there's a queue of 'requests blocked on waiting for some GUI prompt to finish'. Secondly, if multiple requests were blocked on the same key, the code that went over the linked list of them had a bug in which it would unblock the _first_ list item in every iteration, instead of unblocking all the items once each.
2022-06-11 11:46:29 +00:00
PageantSignOp *so = container_of(pkr, PageantSignOp, pkr);
queue_toplevel_callback(pageant_async_op_callback, &so->pao);
}
}
static void unblock_pending_gui_requests(void)
{
for (PageantKeyRequestNode *pkr = requests_blocked_on_gui.next;
pkr != &requests_blocked_on_gui; pkr = pkr->next) {
PageantSignOp *so = container_of(pkr, PageantSignOp, pkr);
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
queue_toplevel_callback(pageant_async_op_callback, &so->pao);
}
}
void pageant_passphrase_request_success(PageantClientDialogId *dlgid,
ptrlen passphrase)
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPrivateKey *priv = container_of(dlgid, PageantPrivateKey, dlgid);
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
Make the Pageant core serialise GUI requests.
2020-02-08 18:08:20 +00:00
assert(gui_request_in_progress);
gui_request_in_progress = false;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
priv->decryption_prompt_active = false;
Make the Pageant core serialise GUI requests.
2020-02-08 18:08:20 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (!priv->skey) {
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
const char *error;
BinarySource src[1];
BinarySource_BARE_INIT_PL(src, ptrlen_from_strbuf(
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
priv->encrypted_key_file));
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
Utility function strbuf_dup. If you already have a string (of potentially-binary data) in the form of a ptrlen reference to somewhere else, and you want to keep a copy somewhere, it's useful to copy it into a strbuf. But it takes a couple of lines of faff to do that, and it's nicer to wrap that up into a tiny helper function. This commit adds that helper function strbuf_dup, and its non-movable sibling strbuf_dup_nm for secret data. Also, gone through the existing code and found a bunch of cases where this makes things less verbose.
2022-04-19 09:53:44 +00:00
strbuf *ppsb = strbuf_dup_nm(passphrase);
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
ssh2_userkey *skey = ppk_load_s(src, ppsb->s, &error);
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
strbuf_free(ppsb);
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (!skey) {
fail_requests_for_key(priv, "unable to decrypt key");
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
return;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
} else if (skey == SSH2_WRONG_PASSPHRASE) {
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
/*
* Find a PageantClient to use for another attempt at
* request_passphrase.
*/
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantKeyRequestNode *pkr = priv->blocked_requests.next;
if (pkr == &priv->blocked_requests) {
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
/*
* Special case: if all the requests have gone away at
* this point, we need not bother putting up a request
* at all any more.
*/
return;
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantSignOp *so = container_of(priv->blocked_requests.next,
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
PageantSignOp, pkr);
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
priv->decryption_prompt_active = false;
if (!request_passphrase(so->pao.info->pc, so->priv)) {
fail_requests_for_key(priv, "unable to continue creating "
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
"passphrase prompts");
}
Assorted bug fixes for runtime passphrase prompts. Now I'm able to use the new feature in a less horrible UI, I'm exploring all the code paths that weren't tested before.
2020-02-08 19:14:14 +00:00
return;
winpgnt: mark encrypted/encryptable keys in GUI key list. Now they have '(encrypted)' or '(re-encryptable)' after them, the same as Unix Pageant. Mostly this just involved tinkering with the code in winpgnt.c that makes up the entry to put in the list box. But I also had to sprinkle a few more calls to keylist_update() into the cross-platform pageant.c, to make sure that the key list window is proactively updated whenever a key is decrypted, re-encrypted, or loaded in encrypted-only form.
2021-04-02 09:13:01 +00:00
} else {
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
priv->skey = skey->key;
sfree(skey->comment);
sfree(skey);
winpgnt: mark encrypted/encryptable keys in GUI key list. Now they have '(encrypted)' or '(re-encryptable)' after them, the same as Unix Pageant. Mostly this just involved tinkering with the code in winpgnt.c that makes up the entry to put in the list box. But I also had to sprinkle a few more calls to keylist_update() into the cross-platform pageant.c, to make sure that the key list window is proactively updated whenever a key is decrypted, re-encrypted, or loaded in encrypted-only form.
2021-04-02 09:13:01 +00:00
keylist_update();
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
}
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
unblock_requests_for_key(priv);
Pageant: fix concurrent attempts to use an encrypted key. If you had a key stored encrypted in Pageant, and you launched two PuTTY sessions both trying to generate a signature with the key, and then didn't type the passphrase into the async passphrase prompt until after both sessions had made requests, then only one of the requests would be replied to once you decrypted the key. The other would sit there waiting for a response that Pageant never got round to sending. This would also happen in the case where you launched two PuTTY sessions each trying to use a _different_ encrypted key in Pageant, in which case Pageant should have presented the next GUI passphrase box after the first one was dismissed. That didn't happen either. This was the result of two separate bugs in the code. Firstly, when signop_coroutine() noticed that a GUI request was already in progress, it would crReturn without making any arrangement to be called back. Now there's a queue of 'requests blocked on waiting for some GUI prompt to finish'. Secondly, if multiple requests were blocked on the same key, the code that went over the linked list of them had a bug in which it would unblock the _first_ list item in every iteration, instead of unblocking all the items once each.
2022-06-11 11:46:29 +00:00
unblock_pending_gui_requests();
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
}
void pageant_passphrase_request_refused(PageantClientDialogId *dlgid)
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPrivateKey *priv = container_of(dlgid, PageantPrivateKey, dlgid);
Make the Pageant core serialise GUI requests.
2020-02-08 18:08:20 +00:00
assert(gui_request_in_progress);
gui_request_in_progress = false;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
priv->decryption_prompt_active = false;
Make the Pageant core serialise GUI requests.
2020-02-08 18:08:20 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
fail_requests_for_key(priv, "user refused to supply passphrase");
Pageant: fix concurrent attempts to use an encrypted key. If you had a key stored encrypted in Pageant, and you launched two PuTTY sessions both trying to generate a signature with the key, and then didn't type the passphrase into the async passphrase prompt until after both sessions had made requests, then only one of the requests would be replied to once you decrypted the key. The other would sit there waiting for a response that Pageant never got round to sending. This would also happen in the case where you launched two PuTTY sessions each trying to use a _different_ encrypted key in Pageant, in which case Pageant should have presented the next GUI passphrase box after the first one was dismissed. That didn't happen either. This was the result of two separate bugs in the code. Firstly, when signop_coroutine() noticed that a GUI request was already in progress, it would crReturn without making any arrangement to be called back. Now there's a queue of 'requests blocked on waiting for some GUI prompt to finish'. Secondly, if multiple requests were blocked on the same key, the code that went over the linked list of them had a bug in which it would unblock the _first_ list item in every iteration, instead of unblocking all the items once each.
2022-06-11 11:46:29 +00:00
unblock_pending_gui_requests();
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +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
typedef struct PageantImmOp PageantImmOp;
struct PageantImmOp {
int crLine;
strbuf *response;
PageantAsyncOp pao;
};
static void immop_free(PageantAsyncOp *pao)
{
PageantImmOp *io = container_of(pao, PageantImmOp, pao);
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
if (io->response)
strbuf_free(io->response);
Pageant: new asynchronous internal APIs. This is a pure refactoring: no functional change expected. This commit introduces two new small vtable-style APIs. One is PageantClient, which identifies a particular client of the Pageant 'core' (meaning the code that handles each individual request). This changes pageant_handle_msg into an asynchronous operation: you pass in an agent request message and an identifier, and at some later point, the got_response method in your PageantClient will be called with the answer (and the same identifier, to allow you to match requests to responses). The trait vtable also contains a logging system. The main importance of PageantClient, and the reason why it has to exist instead of just passing pageant_handle_msg a bare callback function pointer and context parameter, is that it provides robustness if a client stops existing while a request is still pending. You call pageant_unregister_client, and any unfinished requests associated with that client in the Pageant core will be cleaned up, so that you're guaranteed that after the unregister operation, no stray callbacks will happen with a stale pointer to that client. The WM_COPYDATA interface of Windows Pageant is a direct client of this API. The other client is PageantListener, the system that lives in pageant.c and handles stream-based agent connections for both Unix Pageant and the new Windows named-pipe IPC. More specifically, each individual connection to the listening socket is a separate PageantClient, which means that if a socket is closed abruptly or suffers an OS error, that client can be unregistered and any pending requests cancelled without disrupting other connections. Users of PageantListener have a second client vtable they can use, called PageantListenerClient. That contains _only_ logging facilities, and at the moment, only Unix Pageant bothers to use it (and even that only in debugging mode). Finally, internally to the Pageant core, there's a new trait called PageantAsyncOp which describes an agent request in the process of being handled. But at the moment, it has only one trivial implementation, which is handed the full response message already constructed, and on the next toplevel callback, passes it back to the PageantClient.
2020-01-25 17:24:28 +00:00
sfree(io);
}
static void immop_coroutine(PageantAsyncOp *pao)
{
PageantImmOp *io = container_of(pao, PageantImmOp, pao);
crBegin(io->crLine);
if (0) crReturnV;
pageant_client_got_response(io->pao.info->pc, io->pao.reqid,
ptrlen_from_strbuf(io->response));
pageant_async_op_unlink_and_free(&io->pao);
crFinishFreedV;
}
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
static const PageantAsyncOpVtable immop_vtable = {
.coroutine = immop_coroutine,
.free = immop_free,
Pageant: new asynchronous internal APIs. This is a pure refactoring: no functional change expected. This commit introduces two new small vtable-style APIs. One is PageantClient, which identifies a particular client of the Pageant 'core' (meaning the code that handles each individual request). This changes pageant_handle_msg into an asynchronous operation: you pass in an agent request message and an identifier, and at some later point, the got_response method in your PageantClient will be called with the answer (and the same identifier, to allow you to match requests to responses). The trait vtable also contains a logging system. The main importance of PageantClient, and the reason why it has to exist instead of just passing pageant_handle_msg a bare callback function pointer and context parameter, is that it provides robustness if a client stops existing while a request is still pending. You call pageant_unregister_client, and any unfinished requests associated with that client in the Pageant core will be cleaned up, so that you're guaranteed that after the unregister operation, no stray callbacks will happen with a stale pointer to that client. The WM_COPYDATA interface of Windows Pageant is a direct client of this API. The other client is PageantListener, the system that lives in pageant.c and handles stream-based agent connections for both Unix Pageant and the new Windows named-pipe IPC. More specifically, each individual connection to the listening socket is a separate PageantClient, which means that if a socket is closed abruptly or suffers an OS error, that client can be unregistered and any pending requests cancelled without disrupting other connections. Users of PageantListener have a second client vtable they can use, called PageantListenerClient. That contains _only_ logging facilities, and at the moment, only Unix Pageant bothers to use it (and even that only in debugging mode). Finally, internally to the Pageant core, there's a new trait called PageantAsyncOp which describes an agent request in the process of being handled. But at the moment, it has only one trivial implementation, which is handed the full response message already constructed, and on the next toplevel callback, passes it back to the PageantClient.
2020-01-25 17:24:28 +00:00
};
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
static bool reencrypt_key(PageantPublicKey *pub)
Pageant core: extension requests to re-encrypt keys. These requests parallel 'delete key' and 'delete all keys', but they work on keys which you originally uploaded in encrypted form: they cause Pageant to delete only the _decrypted_ form of the key, so that the next attempt to use the key will need to re-prompt for its passphrase.
2020-02-15 16:37:10 +00:00
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPrivateKey *priv = pub_to_priv(pub);
if (priv->sort.ssh_version != 2) {
Pageant core: extension requests to re-encrypt keys. These requests parallel 'delete key' and 'delete all keys', but they work on keys which you originally uploaded in encrypted form: they cause Pageant to delete only the _decrypted_ form of the key, so that the next attempt to use the key will need to re-prompt for its passphrase.
2020-02-15 16:37:10 +00:00
/*
* We don't support storing SSH-1 keys in encrypted form at
* all.
*/
return false;
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (!priv->encrypted_key_file) {
Pageant core: extension requests to re-encrypt keys. These requests parallel 'delete key' and 'delete all keys', but they work on keys which you originally uploaded in encrypted form: they cause Pageant to delete only the _decrypted_ form of the key, so that the next attempt to use the key will need to re-prompt for its passphrase.
2020-02-15 16:37:10 +00:00
/*
* We can't re-encrypt a key if it doesn't have an encrypted
* form. (We could make one up, of course - but with what
* passphrase that we could expect the user to know later?)
*/
return false;
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
/* Only actually free priv->skey if it exists. But we return success
Pageant core: extension requests to re-encrypt keys. These requests parallel 'delete key' and 'delete all keys', but they work on keys which you originally uploaded in encrypted form: they cause Pageant to delete only the _decrypted_ form of the key, so that the next attempt to use the key will need to re-prompt for its passphrase.
2020-02-15 16:37:10 +00:00
* regardless, so that 'please ensure this key isn't stored
* decrypted' is idempotent. */
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (priv->skey) {
ssh_key_free(priv->skey);
priv->skey = NULL;
Pageant core: extension requests to re-encrypt keys. These requests parallel 'delete key' and 'delete all keys', but they work on keys which you originally uploaded in encrypted form: they cause Pageant to delete only the _decrypted_ form of the key, so that the next attempt to use the key will need to re-prompt for its passphrase.
2020-02-15 16:37:10 +00:00
}
return true;
}
Pageant: handle agent extension messages more correctly. Reading draft-miller-ssh-agent-04 more carefully, I see that I missed a few things from the extension-message spec. Firstly, there's an extension request "query" which is supposed to list all the extensions you support. Secondly, if you recognise an extension-request name but are then unable to fulfill the request for some other reason, you're supposed to return a new kind of failure message that's distinct from SSH_AGENT_FAILURE, because for extensions, the latter is reserved for "I don't even know what this extension name means at all". I've fixed both of those bugs in Pageant by making a centralised map of known extension names to an enumeration of internal ids, and an array containing the name for each id. So we can reliably answer the "query" extension by iterating over that array, and also use the same array to recognise known extensions up front and give them centralised processing (in particular, resetting the failure-message type) before switching on the particular extension index.
2020-02-10 20:45:31 +00:00
#define DECL_EXT_ENUM(id, name) id,
enum Extension { KNOWN_EXTENSIONS(DECL_EXT_ENUM) EXT_UNKNOWN };
#define DEF_EXT_NAMES(id, name) PTRLEN_DECL_LITERAL(name),
static const ptrlen extension_names[] = { KNOWN_EXTENSIONS(DEF_EXT_NAMES) };
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
static PageantAsyncOp *pageant_make_op(
PageantClient *pc, PageantClientRequestId *reqid, ptrlen msgpl)
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
{
Pageant server: parse requests using BinarySource. pageant_handle_msg was _particularly_ full of painful manual packet decoding with error checks at every stage, so it's a great relief to throw it all away and replace it with short sequences of calls to the shiny new API!
2018-05-27 22:47:40 +00:00
BinarySource msg[1];
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
strbuf *sb = strbuf_new_nm();
Pageant: handle agent extension messages more correctly. Reading draft-miller-ssh-agent-04 more carefully, I see that I missed a few things from the extension-message spec. Firstly, there's an extension request "query" which is supposed to list all the extensions you support. Secondly, if you recognise an extension-request name but are then unable to fulfill the request for some other reason, you're supposed to return a new kind of failure message that's distinct from SSH_AGENT_FAILURE, because for extensions, the latter is reserved for "I don't even know what this extension name means at all". I've fixed both of those bugs in Pageant by making a centralised map of known extension names to an enumeration of internal ids, and an array containing the name for each id. So we can reliably answer the "query" extension by iterating over that array, and also use the same array to recognise known extensions up front and give them centralised processing (in particular, resetting the failure-message type) before switching on the particular extension index.
2020-02-10 20:45:31 +00:00
unsigned char failure_type = SSH_AGENT_FAILURE;
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
int type;
Pageant: handle agent extension messages more correctly. Reading draft-miller-ssh-agent-04 more carefully, I see that I missed a few things from the extension-message spec. Firstly, there's an extension request "query" which is supposed to list all the extensions you support. Secondly, if you recognise an extension-request name but are then unable to fulfill the request for some other reason, you're supposed to return a new kind of failure message that's distinct from SSH_AGENT_FAILURE, because for extensions, the latter is reserved for "I don't even know what this extension name means at all". I've fixed both of those bugs in Pageant by making a centralised map of known extension names to an enumeration of internal ids, and an array containing the name for each id. So we can reliably answer the "query" extension by iterating over that array, and also use the same array to recognise known extensions up front and give them centralised processing (in particular, resetting the failure-message type) before switching on the particular extension index.
2020-02-10 20:45:31 +00:00
#define fail(...) failure(pc, reqid, sb, failure_type, __VA_ARGS__)
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
BinarySource_BARE_INIT_PL(msg, msgpl);
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Pageant server: parse requests using BinarySource. pageant_handle_msg was _particularly_ full of painful manual packet decoding with error checks at every stage, so it's a great relief to throw it all away and replace it with short sequences of calls to the shiny new API!
2018-05-27 22:47:40 +00:00
type = get_byte(msg);
if (get_err(msg)) {
Pageant: handle agent extension messages more correctly. Reading draft-miller-ssh-agent-04 more carefully, I see that I missed a few things from the extension-message spec. Firstly, there's an extension request "query" which is supposed to list all the extensions you support. Secondly, if you recognise an extension-request name but are then unable to fulfill the request for some other reason, you're supposed to return a new kind of failure message that's distinct from SSH_AGENT_FAILURE, because for extensions, the latter is reserved for "I don't even know what this extension name means at all". I've fixed both of those bugs in Pageant by making a centralised map of known extension names to an enumeration of internal ids, and an array containing the name for each id. So we can reliably answer the "query" extension by iterating over that array, and also use the same array to recognise known extensions up front and give them centralised processing (in particular, resetting the failure-message type) before switching on the particular extension index.
2020-02-10 20:45:31 +00:00
fail("message contained no type code");
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
goto responded;
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
}
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
switch (type) {
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
case SSH1_AGENTC_REQUEST_RSA_IDENTITIES: {
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
/*
* Reply with SSH1_AGENT_RSA_IDENTITIES_ANSWER.
*/
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
pageant_client_log(pc, reqid,
"request: SSH1_AGENTC_REQUEST_RSA_IDENTITIES");
put_byte(sb, SSH1_AGENT_RSA_IDENTITIES_ANSWER);
pageant_make_keylist1(BinarySink_UPCAST(sb));
pageant_client_log(pc, reqid,
"reply: SSH1_AGENT_RSA_IDENTITIES_ANSWER");
if (!pc->suppress_logging) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
int i;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub;
for (i = 0; NULL != (pub = pageant_nth_pubkey(1, i)); i++) {
PageantPrivateKey *priv = pub_to_priv(pub);
char *fingerprint = rsa_ssh1_fingerprint(priv->rkey);
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid, "returned key: %s",
fingerprint);
sfree(fingerprint);
}
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
}
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
case SSH2_AGENTC_REQUEST_IDENTITIES: {
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
/*
* Reply with SSH2_AGENT_IDENTITIES_ANSWER.
*/
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
pageant_client_log(pc, reqid,
"request: SSH2_AGENTC_REQUEST_IDENTITIES");
put_byte(sb, SSH2_AGENT_IDENTITIES_ANSWER);
pageant_make_keylist2(BinarySink_UPCAST(sb));
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid, "reply: SSH2_AGENT_IDENTITIES_ANSWER");
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (!pc->suppress_logging) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
int i;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub;
for (i = 0; NULL != (pub = pageant_nth_pubkey(2, i)); i++) {
Certificate-aware handling of key fingerprints. OpenSSH, when called on to give the fingerprint of a certified public key, will in many circumstances generate the hash of the public blob of the _underlying_ key, rather than the hash of the full certificate. I think the hash of the certificate is also potentially useful (if nothing else, it provides a way to tell apart multiple certificates on the same key). But I can also see that it's useful to be able to recognise a key as the same one 'really' (since all certificates on the same key share a private key, so they're unavoidably related). So I've dealt with this by introducing an extra pair of fingerprint types, giving the cross product of {MD5, SHA-256} x {base key only, full certificate}. You can manually select which one you want to see in some circumstances (notably PuTTYgen), and in others (such as diagnostics) both fingerprints will be emitted side by side via the new functions ssh2_double_fingerprint[_blob]. The default, following OpenSSH, is to just fingerprint the base key.
2022-08-05 17:08:59 +00:00
char *fingerprint = ssh2_double_fingerprint_blob(
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
pub->sort.full_pub, SSH_FPTYPE_DEFAULT);
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid, "returned key: %s %s",
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
fingerprint, pub->comment);
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
sfree(fingerprint);
}
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
}
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
case SSH1_AGENTC_RSA_CHALLENGE: {
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
/*
* Reply with either SSH1_AGENT_RSA_RESPONSE or
* SSH_AGENT_FAILURE, depending on whether we have that key
* or not.
*/
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
RSAKey reqkey;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub;
PageantPrivateKey *priv;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
mp_int *challenge, *response;
ptrlen session_id;
unsigned response_type;
unsigned char response_md5[16];
int i;
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid, "request: SSH1_AGENTC_RSA_CHALLENGE");
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
response = NULL;
memset(&reqkey, 0, sizeof(reqkey));
get_rsa_ssh1_pub(msg, &reqkey, RSA_SSH1_EXPONENT_FIRST);
challenge = get_mp_ssh1(msg);
session_id = get_data(msg, 16);
response_type = get_uint32(msg);
if (get_err(msg)) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("unable to decode request");
goto challenge1_cleanup;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
if (response_type != 1) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("response type other than 1 not supported");
goto challenge1_cleanup;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Pageant server: parse requests using BinarySource. pageant_handle_msg was _particularly_ full of painful manual packet decoding with error checks at every stage, so it's a great relief to throw it all away and replace it with short sequences of calls to the shiny new API!
2018-05-27 22:47:40 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (!pc->suppress_logging) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
char *fingerprint;
reqkey.comment = NULL;
fingerprint = rsa_ssh1_fingerprint(&reqkey);
pageant_client_log(pc, reqid, "requested key: %s", fingerprint);
sfree(fingerprint);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Pageant server: parse requests using BinarySource. pageant_handle_msg was _particularly_ full of painful manual packet decoding with error checks at every stage, so it's a great relief to throw it all away and replace it with short sequences of calls to the shiny new API!
2018-05-27 22:47:40 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if ((pub = findpubkey1(&reqkey)) == NULL) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("key not found");
goto challenge1_cleanup;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
priv = pub_to_priv(pub);
response = rsa_ssh1_decrypt(challenge, priv->rkey);
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
{
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
ssh_hash *h = ssh_hash_new(&ssh_md5);
for (i = 0; i < 32; i++)
put_byte(h, mp_get_byte(response, 31 - i));
put_datapl(h, session_id);
ssh_hash_final(h, response_md5);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
put_byte(sb, SSH1_AGENT_RSA_RESPONSE);
put_data(sb, response_md5, 16);
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
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
pageant_client_log(pc, reqid, "reply: SSH1_AGENT_RSA_RESPONSE");
Build SSH agent reply messages in a BinarySink. This gets rid of yet another huge pile of beating around the bush with length-counting. Also, this time, the BinarySink in question is a little more interesting than just being a strbuf every time: on Windows, where the shared-memory Pageant IPC system imposes a hard limit on the size of message we can return, I've written a custom BinarySink implementation that collects up to that much data and then gives up and sets an overflow flag rather than continue to allocate memory. So the main Pageant code no longer has to worry about checking AGENT_MAX_MSGLEN all the time - and better still, the Unix version of Pageant is no longer _limited_ by AGENT_MAX_MSGLEN in its outgoing messages, i.e. it could store a really extra large number of keys if it needed to. That limitation is now a local feature of Windows Pageant rather than intrinsic to the whole code base. (AGENT_MAX_MSGLEN is still used to check incoming agent messages for sanity, however. Mostly that's because I feel I ought to check them against _some_ limit, and this one seems sensible enough. Incoming agent messages are more bounded anyway - they generally don't hold more than _one_ private key.)
2018-05-24 12:23:17 +00:00
Formatting: another handful of mis-indented labels. These were indented 2 spaces _further_ than the surrounding code, instead of 2 spaces less. My bulk-reindentation the other day didn't detect them because apparently my Emacs configuration can make this mistake all by itself, so it thought they were right!
2022-08-07 17:41:57 +00:00
challenge1_cleanup:
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (response)
mp_free(response);
mp_free(challenge);
freersakey(&reqkey);
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
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
case SSH2_AGENTC_SIGN_REQUEST: {
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
/*
* Reply with either SSH2_AGENT_SIGN_RESPONSE or
* SSH_AGENT_FAILURE, depending on whether we have that key
* or not.
*/
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
ptrlen keyblob, sigdata;
uint32_t flags;
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
pageant_client_log(pc, reqid, "request: SSH2_AGENTC_SIGN_REQUEST");
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
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
keyblob = get_string(msg);
sigdata = get_string(msg);
Support flags word in SSH2_AGENTC_SIGN_REQUEST. A couple of people have mentioned to me recently that these days OpenSSH is appending a uint32 flags word to the agent sign request, with flags that ask for an RSA signature to be over a SHA-256 or SHA-512 hash instead of the SHA-1 standardised in ssh-rsa. This commit adds support for the mandatory part of this protocol: we notice the flags word at all (previously we stopped parsing the packet before even finding it there), and return failure to the signing request if it has any flag set that we don't support, which currently means if it has any flag set whatsoever. While I'm here, I've also added an error check for an undecodable sign request. (It seemed silly to be checking get_err(msg) _after_ trying to read the flags word without also having checked it before.)
2018-11-19 20:20:00 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (get_err(msg)) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("unable to decode request");
goto responded;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Build SSH agent reply messages in a BinarySink. This gets rid of yet another huge pile of beating around the bush with length-counting. Also, this time, the BinarySink in question is a little more interesting than just being a strbuf every time: on Windows, where the shared-memory Pageant IPC system imposes a hard limit on the size of message we can return, I've written a custom BinarySink implementation that collects up to that much data and then gives up and sets an overflow flag rather than continue to allocate memory. So the main Pageant code no longer has to worry about checking AGENT_MAX_MSGLEN all the time - and better still, the Unix version of Pageant is no longer _limited_ by AGENT_MAX_MSGLEN in its outgoing messages, i.e. it could store a really extra large number of keys if it needed to. That limitation is now a local feature of Windows Pageant rather than intrinsic to the whole code base. (AGENT_MAX_MSGLEN is still used to check incoming agent messages for sanity, however. Mostly that's because I feel I ought to check them against _some_ limit, and this one seems sensible enough. Incoming agent messages are more bounded anyway - they generally don't hold more than _one_ private key.)
2018-05-24 12:23:17 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
/*
* Later versions of the agent protocol added a flags word
* on the end of the sign request. That hasn't always been
* there, so we don't complain if we don't find it.
*
* get_uint32 will default to returning zero if no data is
* available.
*/
bool have_flags = false;
flags = get_uint32(msg);
if (!get_err(msg))
have_flags = true;
if (!pc->suppress_logging) {
Certificate-aware handling of key fingerprints. OpenSSH, when called on to give the fingerprint of a certified public key, will in many circumstances generate the hash of the public blob of the _underlying_ key, rather than the hash of the full certificate. I think the hash of the certificate is also potentially useful (if nothing else, it provides a way to tell apart multiple certificates on the same key). But I can also see that it's useful to be able to recognise a key as the same one 'really' (since all certificates on the same key share a private key, so they're unavoidably related). So I've dealt with this by introducing an extra pair of fingerprint types, giving the cross product of {MD5, SHA-256} x {base key only, full certificate}. You can manually select which one you want to see in some circumstances (notably PuTTYgen), and in others (such as diagnostics) both fingerprints will be emitted side by side via the new functions ssh2_double_fingerprint[_blob]. The default, following OpenSSH, is to just fingerprint the base key.
2022-08-05 17:08:59 +00:00
char *fingerprint = ssh2_double_fingerprint_blob(
Introduce OpenSSH-compatible SHA256 key fingerprinting. There's a new enumeration of fingerprint types, and you tell ssh2_fingerprint() or ssh2_fingerprint_blob() which of them to use. So far, this is only implemented behind the scenes, and exposed for testcrypt to test. All the call sites of ssh2_fingerprint pass a fixed default fptype, which is still set to the old MD5. That will change shortly.
2021-03-13 09:52:56 +00:00
keyblob, SSH_FPTYPE_DEFAULT);
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid, "requested key: %s", fingerprint);
sfree(fingerprint);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if ((pub = findpubkey2(keyblob)) == NULL) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("key not found");
goto responded;
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
}
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (have_flags)
pageant_client_log(pc, reqid, "signature flags = 0x%08"PRIx32,
flags);
else
pageant_client_log(pc, reqid, "no signature flags");
strbuf_free(sb); /* no immediate response */
PageantSignOp *so = snew(PageantSignOp);
so->pao.vt = &signop_vtable;
so->pao.info = pc->info;
so->pao.cr.prev = pc->info->head.prev;
so->pao.cr.next = &pc->info->head;
Pageant: actually link requests on to their queues. When I create any class that implements PageantAsyncOp, I had intended to link its pao.cr list node on to the list in the appropriate PageantClientInfo, so that if that PageantClientInfo was destroyed prematurely (e.g. an agent connection was abruptly closed), we could destroy all the pending requests containing a pointer to it. I did this linking by setting the linked-list fields in pao.cr to point to the appropriate places in the existing list - but I didn't modify the pointer fields _in_ the existing list to point to the new operation at all. So nothing ever actually got linked on to any of those queues!
2021-09-30 17:56:26 +00:00
so->pao.cr.prev->next = so->pao.cr.next->prev = &so->pao.cr;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
so->pao.reqid = reqid;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
so->priv = pub_to_priv(pub);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
so->pkr.prev = so->pkr.next = NULL;
Utility function strbuf_dup. If you already have a string (of potentially-binary data) in the form of a ptrlen reference to somewhere else, and you want to keep a copy somewhere, it's useful to copy it into a strbuf. But it takes a couple of lines of faff to do that, and it's nicer to wrap that up into a tiny helper function. This commit adds that helper function strbuf_dup, and its non-movable sibling strbuf_dup_nm for secret data. Also, gone through the existing code and found a bunch of cases where this makes things less verbose.
2022-04-19 09:53:44 +00:00
so->data_to_sign = strbuf_dup(sigdata);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
so->flags = flags;
so->failure_type = failure_type;
so->crLine = 0;
return &so->pao;
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
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
case SSH1_AGENTC_ADD_RSA_IDENTITY: {
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
/*
* Add to the list and return SSH_AGENT_SUCCESS, or
* SSH_AGENT_FAILURE if the key was malformed.
*/
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
RSAKey *key;
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid, "request: SSH1_AGENTC_ADD_RSA_IDENTITY");
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
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
key = get_rsa_ssh1_priv_agent(msg);
key->comment = mkstr(get_string(msg));
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (get_err(msg)) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("unable to decode request");
goto add1_cleanup;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (!rsa_verify(key)) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("key is invalid");
goto add1_cleanup;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Pageant: verify SSH-1 RSA keys before accepting them. In Friday's testing of the BinarySink work, I noticed that if you accidentally add a mathematically invalid RSA1 key to Pageant, it will accept it, getting into a state where it can fail assertions when asked to use the key later. Added a call to rsa_verify(), triggering an SSH_AGENT_FAILURE response if it doesn't agree the key is good.
2018-05-26 17:00:23 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (!pc->suppress_logging) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
char *fingerprint = rsa_ssh1_fingerprint(key);
pageant_client_log(pc, reqid,
"submitted key: %s", fingerprint);
sfree(fingerprint);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
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
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (pageant_add_ssh1_key(key)) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
keylist_update();
put_byte(sb, SSH_AGENT_SUCCESS);
pageant_client_log(pc, reqid, "reply: SSH_AGENT_SUCCESS");
key = NULL; /* don't free it in cleanup */
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
} else {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("key already present");
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Build SSH agent reply messages in a BinarySink. This gets rid of yet another huge pile of beating around the bush with length-counting. Also, this time, the BinarySink in question is a little more interesting than just being a strbuf every time: on Windows, where the shared-memory Pageant IPC system imposes a hard limit on the size of message we can return, I've written a custom BinarySink implementation that collects up to that much data and then gives up and sets an overflow flag rather than continue to allocate memory. So the main Pageant code no longer has to worry about checking AGENT_MAX_MSGLEN all the time - and better still, the Unix version of Pageant is no longer _limited_ by AGENT_MAX_MSGLEN in its outgoing messages, i.e. it could store a really extra large number of keys if it needed to. That limitation is now a local feature of Windows Pageant rather than intrinsic to the whole code base. (AGENT_MAX_MSGLEN is still used to check incoming agent messages for sanity, however. Mostly that's because I feel I ought to check them against _some_ limit, and this one seems sensible enough. Incoming agent messages are more bounded anyway - they generally don't hold more than _one_ private key.)
2018-05-24 12:23:17 +00:00
Formatting: another handful of mis-indented labels. These were indented 2 spaces _further_ than the surrounding code, instead of 2 spaces less. My bulk-reindentation the other day didn't detect them because apparently my Emacs configuration can make this mistake all by itself, so it thought they were right!
2022-08-07 17:41:57 +00:00
add1_cleanup:
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (key) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
freersakey(key);
sfree(key);
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
}
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
case SSH2_AGENTC_ADD_IDENTITY: {
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
/*
* Add to the list and return SSH_AGENT_SUCCESS, or
* SSH_AGENT_FAILURE if the key was malformed.
*/
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
ssh2_userkey *key = NULL;
ptrlen algpl;
const ssh_keyalg *alg;
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
pageant_client_log(pc, reqid, "request: SSH2_AGENTC_ADD_IDENTITY");
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
algpl = get_string(msg);
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
key = snew(ssh2_userkey);
key->key = NULL;
key->comment = NULL;
alg = find_pubkey_alg_len(algpl);
if (!alg) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("algorithm unknown");
goto add2_cleanup;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
key->key = ssh_key_new_priv_openssh(alg, msg);
Pageant server: parse requests using BinarySource. pageant_handle_msg was _particularly_ full of painful manual packet decoding with error checks at every stage, so it's a great relief to throw it all away and replace it with short sequences of calls to the shiny new API!
2018-05-27 22:47:40 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (!key->key) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("key setup failed");
goto add2_cleanup;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
key->comment = mkstr(get_string(msg));
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (get_err(msg)) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("unable to decode request");
goto add2_cleanup;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (!pc->suppress_logging) {
Introduce OpenSSH-compatible SHA256 key fingerprinting. There's a new enumeration of fingerprint types, and you tell ssh2_fingerprint() or ssh2_fingerprint_blob() which of them to use. So far, this is only implemented behind the scenes, and exposed for testcrypt to test. All the call sites of ssh2_fingerprint pass a fixed default fptype, which is still set to the old MD5. That will change shortly.
2021-03-13 09:52:56 +00:00
char *fingerprint = ssh2_fingerprint(key->key, SSH_FPTYPE_DEFAULT);
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid, "submitted key: %s %s",
fingerprint, key->comment);
sfree(fingerprint);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
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
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (pageant_add_ssh2_key(key)) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
keylist_update();
put_byte(sb, SSH_AGENT_SUCCESS);
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
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid, "reply: SSH_AGENT_SUCCESS");
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
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
key = NULL; /* don't clean it up */
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
} else {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("key already present");
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Build SSH agent reply messages in a BinarySink. This gets rid of yet another huge pile of beating around the bush with length-counting. Also, this time, the BinarySink in question is a little more interesting than just being a strbuf every time: on Windows, where the shared-memory Pageant IPC system imposes a hard limit on the size of message we can return, I've written a custom BinarySink implementation that collects up to that much data and then gives up and sets an overflow flag rather than continue to allocate memory. So the main Pageant code no longer has to worry about checking AGENT_MAX_MSGLEN all the time - and better still, the Unix version of Pageant is no longer _limited_ by AGENT_MAX_MSGLEN in its outgoing messages, i.e. it could store a really extra large number of keys if it needed to. That limitation is now a local feature of Windows Pageant rather than intrinsic to the whole code base. (AGENT_MAX_MSGLEN is still used to check incoming agent messages for sanity, however. Mostly that's because I feel I ought to check them against _some_ limit, and this one seems sensible enough. Incoming agent messages are more bounded anyway - they generally don't hold more than _one_ private key.)
2018-05-24 12:23:17 +00:00
Formatting: another handful of mis-indented labels. These were indented 2 spaces _further_ than the surrounding code, instead of 2 spaces less. My bulk-reindentation the other day didn't detect them because apparently my Emacs configuration can make this mistake all by itself, so it thought they were right!
2022-08-07 17:41:57 +00:00
add2_cleanup:
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (key) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
if (key->key)
ssh_key_free(key->key);
if (key->comment)
sfree(key->comment);
sfree(key);
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
}
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
case SSH1_AGENTC_REMOVE_RSA_IDENTITY: {
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
/*
* Remove from the list and return SSH_AGENT_SUCCESS, or
* perhaps SSH_AGENT_FAILURE if it wasn't in the list to
* start with.
*/
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
RSAKey reqkey;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub;
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
pageant_client_log(pc, reqid,
"request: SSH1_AGENTC_REMOVE_RSA_IDENTITY");
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
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
memset(&reqkey, 0, sizeof(reqkey));
get_rsa_ssh1_pub(msg, &reqkey, RSA_SSH1_EXPONENT_FIRST);
Pageant server: parse requests using BinarySource. pageant_handle_msg was _particularly_ full of painful manual packet decoding with error checks at every stage, so it's a great relief to throw it all away and replace it with short sequences of calls to the shiny new API!
2018-05-27 22:47:40 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (get_err(msg)) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("unable to decode request");
freersakey(&reqkey);
goto responded;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
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
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (!pc->suppress_logging) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
char *fingerprint;
reqkey.comment = NULL;
fingerprint = rsa_ssh1_fingerprint(&reqkey);
pageant_client_log(pc, reqid, "unwanted key: %s", fingerprint);
sfree(fingerprint);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
pub = findpubkey1(&reqkey);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
freersakey(&reqkey);
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (pub) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid, "found with comment: %s",
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
pub->comment);
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
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
del_pubkey(pub);
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
keylist_update();
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
pk_pub_free(pub);
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
put_byte(sb, SSH_AGENT_SUCCESS);
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
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid, "reply: SSH_AGENT_SUCCESS");
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
} else {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("key not found");
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
}
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
case SSH2_AGENTC_REMOVE_IDENTITY: {
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
/*
* Remove from the list and return SSH_AGENT_SUCCESS, or
* perhaps SSH_AGENT_FAILURE if it wasn't in the list to
* start with.
*/
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
ptrlen blob;
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid, "request: SSH2_AGENTC_REMOVE_IDENTITY");
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
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
blob = get_string(msg);
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (get_err(msg)) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("unable to decode request");
goto responded;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (!pc->suppress_logging) {
Certificate-aware handling of key fingerprints. OpenSSH, when called on to give the fingerprint of a certified public key, will in many circumstances generate the hash of the public blob of the _underlying_ key, rather than the hash of the full certificate. I think the hash of the certificate is also potentially useful (if nothing else, it provides a way to tell apart multiple certificates on the same key). But I can also see that it's useful to be able to recognise a key as the same one 'really' (since all certificates on the same key share a private key, so they're unavoidably related). So I've dealt with this by introducing an extra pair of fingerprint types, giving the cross product of {MD5, SHA-256} x {base key only, full certificate}. You can manually select which one you want to see in some circumstances (notably PuTTYgen), and in others (such as diagnostics) both fingerprints will be emitted side by side via the new functions ssh2_double_fingerprint[_blob]. The default, following OpenSSH, is to just fingerprint the base key.
2022-08-05 17:08:59 +00:00
char *fingerprint = ssh2_double_fingerprint_blob(
Introduce OpenSSH-compatible SHA256 key fingerprinting. There's a new enumeration of fingerprint types, and you tell ssh2_fingerprint() or ssh2_fingerprint_blob() which of them to use. So far, this is only implemented behind the scenes, and exposed for testcrypt to test. All the call sites of ssh2_fingerprint pass a fixed default fptype, which is still set to the old MD5. That will change shortly.
2021-03-13 09:52:56 +00:00
blob, SSH_FPTYPE_DEFAULT);
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid, "unwanted key: %s", fingerprint);
sfree(fingerprint);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
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
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
pub = findpubkey2(blob);
if (!pub) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("key not found");
goto responded;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
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
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
pageant_client_log(pc, reqid, "found with comment: %s", pub->comment);
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
del_pubkey(pub);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
keylist_update();
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
pk_pub_free(pub);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
put_byte(sb, SSH_AGENT_SUCCESS);
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
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
pageant_client_log(pc, reqid, "reply: SSH_AGENT_SUCCESS");
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
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
case SSH1_AGENTC_REMOVE_ALL_RSA_IDENTITIES: {
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
/*
* Remove all SSH-1 keys. Always returns success.
*/
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid,
"request: SSH1_AGENTC_REMOVE_ALL_RSA_IDENTITIES");
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
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
remove_all_keys(1);
keylist_update();
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
put_byte(sb, SSH_AGENT_SUCCESS);
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
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
pageant_client_log(pc, reqid, "reply: SSH_AGENT_SUCCESS");
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
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
case SSH2_AGENTC_REMOVE_ALL_IDENTITIES: {
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
/*
* Remove all SSH-2 keys. Always returns success.
*/
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
pageant_client_log(pc, reqid,
"request: SSH2_AGENTC_REMOVE_ALL_IDENTITIES");
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
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
remove_all_keys(2);
keylist_update();
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
put_byte(sb, SSH_AGENT_SUCCESS);
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
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
pageant_client_log(pc, reqid, "reply: SSH_AGENT_SUCCESS");
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
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
case SSH2_AGENTC_EXTENSION: {
enum Extension exttype = EXT_UNKNOWN;
ptrlen extname = get_string(msg);
pageant_client_log(pc, reqid,
"request: SSH2_AGENTC_EXTENSION \"%.*s\"",
PTRLEN_PRINTF(extname));
for (size_t i = 0; i < lenof(extension_names); i++)
if (ptrlen_eq_ptrlen(extname, extension_names[i])) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
exttype = i;
/*
* For SSH_AGENTC_EXTENSION requests, the message
* code SSH_AGENT_FAILURE is reserved for "I don't
* recognise this extension name at all". For any
* other kind of failure while processing an
* extension we _do_ recognise, we must switch to
* returning a different failure code, with
* semantics "I understood the extension name, but
* something else went wrong".
*/
failure_type = SSH_AGENT_EXTENSION_FAILURE;
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Pageant core: extension requests to re-encrypt keys. These requests parallel 'delete key' and 'delete all keys', but they work on keys which you originally uploaded in encrypted form: they cause Pageant to delete only the _decrypted_ form of the key, so that the next attempt to use the key will need to re-prompt for its passphrase.
2020-02-15 16:37:10 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
switch (exttype) {
case EXT_UNKNOWN:
fail("unrecognised extension name '%.*s'",
PTRLEN_PRINTF(extname));
break;
case EXT_QUERY:
/* Standard request to list the supported extensions. */
put_byte(sb, SSH_AGENT_SUCCESS);
Pageant: handle agent extension messages more correctly. Reading draft-miller-ssh-agent-04 more carefully, I see that I missed a few things from the extension-message spec. Firstly, there's an extension request "query" which is supposed to list all the extensions you support. Secondly, if you recognise an extension-request name but are then unable to fulfill the request for some other reason, you're supposed to return a new kind of failure message that's distinct from SSH_AGENT_FAILURE, because for extensions, the latter is reserved for "I don't even know what this extension name means at all". I've fixed both of those bugs in Pageant by making a centralised map of known extension names to an enumeration of internal ids, and an array containing the name for each id. So we can reliably answer the "query" extension by iterating over that array, and also use the same array to recognise known extensions up front and give them centralised processing (in particular, resetting the failure-message type) before switching on the particular extension index.
2020-02-10 20:45:31 +00:00
for (size_t i = 0; i < lenof(extension_names); i++)
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
put_stringpl(sb, extension_names[i]);
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid, "reply: SSH_AGENT_SUCCESS + names");
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
break;
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
case EXT_ADD_PPK: {
ptrlen keyfile = get_string(msg);
Pageant core: extension requests to re-encrypt keys. These requests parallel 'delete key' and 'delete all keys', but they work on keys which you originally uploaded in encrypted form: they cause Pageant to delete only the _decrypted_ form of the key, so that the next attempt to use the key will need to re-prompt for its passphrase.
2020-02-15 16:37:10 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (get_err(msg)) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("unable to decode request");
goto responded;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Pageant core: extension requests to re-encrypt keys. These requests parallel 'delete key' and 'delete all keys', but they work on keys which you originally uploaded in encrypted form: they cause Pageant to delete only the _decrypted_ form of the key, so that the next attempt to use the key will need to re-prompt for its passphrase.
2020-02-15 16:37:10 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
strbuf *base_pub = NULL;
strbuf *full_pub = NULL;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
BinarySource src[1];
const char *error;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
full_pub = strbuf_new();
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
char *comment;
Pageant core: extension requests to re-encrypt keys. These requests parallel 'delete key' and 'delete all keys', but they work on keys which you originally uploaded in encrypted form: they cause Pageant to delete only the _decrypted_ form of the key, so that the next attempt to use the key will need to re-prompt for its passphrase.
2020-02-15 16:37:10 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
BinarySource_BARE_INIT_PL(src, keyfile);
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (!ppk_loadpub_s(src, NULL, BinarySink_UPCAST(full_pub),
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
&comment, &error)) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("failed to extract public key blob: %s", error);
goto add_ppk_cleanup;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
if (!pc->suppress_logging) {
Certificate-aware handling of key fingerprints. OpenSSH, when called on to give the fingerprint of a certified public key, will in many circumstances generate the hash of the public blob of the _underlying_ key, rather than the hash of the full certificate. I think the hash of the certificate is also potentially useful (if nothing else, it provides a way to tell apart multiple certificates on the same key). But I can also see that it's useful to be able to recognise a key as the same one 'really' (since all certificates on the same key share a private key, so they're unavoidably related). So I've dealt with this by introducing an extra pair of fingerprint types, giving the cross product of {MD5, SHA-256} x {base key only, full certificate}. You can manually select which one you want to see in some circumstances (notably PuTTYgen), and in others (such as diagnostics) both fingerprints will be emitted side by side via the new functions ssh2_double_fingerprint[_blob]. The default, following OpenSSH, is to just fingerprint the base key.
2022-08-05 17:08:59 +00:00
char *fingerprint = ssh2_double_fingerprint_blob(
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
ptrlen_from_strbuf(full_pub), SSH_FPTYPE_DEFAULT);
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid, "add-ppk: %s %s",
fingerprint, comment);
sfree(fingerprint);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Pageant core: extension requests to re-encrypt keys. These requests parallel 'delete key' and 'delete all keys', but they work on keys which you originally uploaded in encrypted form: they cause Pageant to delete only the _decrypted_ form of the key, so that the next attempt to use the key will need to re-prompt for its passphrase.
2020-02-15 16:37:10 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
BinarySource_BARE_INIT_PL(src, keyfile);
bool encrypted = ppk_encrypted_s(src, NULL);
if (!encrypted) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
/* If the key isn't encrypted, then we should just
* load and add it in the obvious way. */
BinarySource_BARE_INIT_PL(src, keyfile);
ssh2_userkey *skey = ppk_load_s(src, NULL, &error);
if (!skey) {
fail("failed to decode private key: %s", error);
} else if (pageant_add_ssh2_key(skey)) {
keylist_update();
put_byte(sb, SSH_AGENT_SUCCESS);
pageant_client_log(pc, reqid, "reply: SSH_AGENT_SUCCESS"
" (loaded unencrypted PPK)");
} else {
fail("key already present");
if (skey->key)
ssh_key_free(skey->key);
if (skey->comment)
sfree(skey->comment);
sfree(skey);
}
goto add_ppk_cleanup;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Pageant core: extension requests to re-encrypt keys. These requests parallel 'delete key' and 'delete all keys', but they work on keys which you originally uploaded in encrypted form: they cause Pageant to delete only the _decrypted_ form of the key, so that the next attempt to use the key will need to re-prompt for its passphrase.
2020-02-15 16:37:10 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKeySort sort;
sort.priv.ssh_version = 2;
sort.full_pub = ptrlen_from_strbuf(full_pub);
base_pub = make_base_pub_2(&sort);
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
pageant_add_ssh2_key_encrypted(sort, comment, keyfile);
keylist_update();
put_byte(sb, SSH_AGENT_SUCCESS);
pageant_client_log(pc, reqid, "reply: SSH_AGENT_SUCCESS");
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
add_ppk_cleanup:
if (full_pub)
strbuf_free(full_pub);
if (base_pub)
strbuf_free(base_pub);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
sfree(comment);
break;
}
case EXT_REENCRYPT: {
/*
* Re-encrypt a single key, in the sense of deleting
* its unencrypted copy, returning it to the state of
* only having the encrypted PPK form stored, so that
* the next attempt to use it will have to re-prompt
* for the passphrase.
*/
ptrlen blob = get_string(msg);
if (get_err(msg)) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("unable to decode request");
goto responded;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
if (!pc->suppress_logging) {
Certificate-aware handling of key fingerprints. OpenSSH, when called on to give the fingerprint of a certified public key, will in many circumstances generate the hash of the public blob of the _underlying_ key, rather than the hash of the full certificate. I think the hash of the certificate is also potentially useful (if nothing else, it provides a way to tell apart multiple certificates on the same key). But I can also see that it's useful to be able to recognise a key as the same one 'really' (since all certificates on the same key share a private key, so they're unavoidably related). So I've dealt with this by introducing an extra pair of fingerprint types, giving the cross product of {MD5, SHA-256} x {base key only, full certificate}. You can manually select which one you want to see in some circumstances (notably PuTTYgen), and in others (such as diagnostics) both fingerprints will be emitted side by side via the new functions ssh2_double_fingerprint[_blob]. The default, following OpenSSH, is to just fingerprint the base key.
2022-08-05 17:08:59 +00:00
char *fingerprint = ssh2_double_fingerprint_blob(
Introduce OpenSSH-compatible SHA256 key fingerprinting. There's a new enumeration of fingerprint types, and you tell ssh2_fingerprint() or ssh2_fingerprint_blob() which of them to use. So far, this is only implemented behind the scenes, and exposed for testcrypt to test. All the call sites of ssh2_fingerprint pass a fixed default fptype, which is still set to the old MD5. That will change shortly.
2021-03-13 09:52:56 +00:00
blob, SSH_FPTYPE_DEFAULT);
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
pageant_client_log(pc, reqid, "key to re-encrypt: %s",
fingerprint);
sfree(fingerprint);
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
}
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub = findpubkey2(blob);
if (!pub) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("key not found");
goto responded;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
pageant_client_log(pc, reqid,
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
"found with comment: %s", pub->comment);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
if (!reencrypt_key(pub)) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("this key couldn't be re-encrypted");
goto responded;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
winpgnt: mark encrypted/encryptable keys in GUI key list. Now they have '(encrypted)' or '(re-encryptable)' after them, the same as Unix Pageant. Mostly this just involved tinkering with the code in winpgnt.c that makes up the entry to put in the list box. But I also had to sprinkle a few more calls to keylist_update() into the cross-platform pageant.c, to make sure that the key list window is proactively updated whenever a key is decrypted, re-encrypted, or loaded in encrypted-only form.
2021-04-02 09:13:01 +00:00
keylist_update();
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
put_byte(sb, SSH_AGENT_SUCCESS);
pageant_client_log(pc, reqid, "reply: SSH_AGENT_SUCCESS");
break;
}
case EXT_REENCRYPT_ALL: {
/*
* Re-encrypt all keys that have an encrypted form
* stored. Usually, returns success, but with a uint32
* appended indicating how many keys remain
* unencrypted. The exception is if there is at least
* one key in the agent and _no_ key was successfully
* re-encrypted; in that situation we've done nothing,
* and the client didn't _want_ us to do nothing, so
* we return failure.
*
* (Rationale: the 'failure' message ought to be
* atomic, that is, you shouldn't return failure
* having made a state change.)
*/
unsigned nfailures = 0, nsuccesses = 0;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
for (int i = 0; (pub = index234(pubkeytree, i)) != NULL; i++) {
if (reencrypt_key(pub))
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
nsuccesses++;
else
nfailures++;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
if (nsuccesses == 0 && nfailures > 0) {
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
fail("no key could be re-encrypted");
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
} else {
winpgnt: mark encrypted/encryptable keys in GUI key list. Now they have '(encrypted)' or '(re-encryptable)' after them, the same as Unix Pageant. Mostly this just involved tinkering with the code in winpgnt.c that makes up the entry to put in the list box. But I also had to sprinkle a few more calls to keylist_update() into the cross-platform pageant.c, to make sure that the key list window is proactively updated whenever a key is decrypted, re-encrypted, or loaded in encrypted-only form.
2021-04-02 09:13:01 +00:00
keylist_update();
Pageant: reindent the main handler function. Somehow it had acquired a lot of internal 2-space indentation, which is out of step with the rest of this code base's style. Before I get into making more changes in here, let's clean it up.
2020-12-15 13:04:13 +00:00
put_byte(sb, SSH_AGENT_SUCCESS);
put_uint32(sb, nfailures);
pageant_client_log(pc, reqid, "reply: SSH_AGENT_SUCCESS "
"(%u keys re-encrypted, %u failures)",
nsuccesses, nfailures);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
break;
}
Pageant: new PuTTY-specific ext request, 'list-extended'. This is an extended version of SSH2_AGENTC_REQUEST_IDENTITIES, which augments each entry in the returned key list with an extra field containing additional data about the key. The initial contents of that extra field are a pair of flags indicating whether the key is currently stored in the agent encrypted, decrypted or both. The idea is that this will permit a Pageant-aware client to make decisions based on that. For a start, the output key list can mention it to the user; also, if you try to add a key unencrypted when it's already present, we can discriminate based on whether it's already present _unencrypted_
2020-12-15 13:25:45 +00:00
case EXT_LIST_EXTENDED: {
/*
* Return a key list like SSH2_AGENTC_REQUEST_IDENTITIES,
* except that each key is annotated with extra
* information such as whether it's currently encrypted.
*
* The return message type is AGENT_SUCCESS with auxiliary
* data, which is more like other extension messages. I
* think it would be confusing to reuse IDENTITIES_ANSWER
* for a reply message with an incompatible format.
*/
put_byte(sb, SSH_AGENT_SUCCESS);
pageant_make_keylist_extended(BinarySink_UPCAST(sb));
pageant_client_log(pc, reqid,
"reply: SSH2_AGENT_SUCCESS + key list");
if (!pc->suppress_logging) {
int i;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub;
for (i = 0; NULL != (pub = pageant_nth_pubkey(2, i)); i++) {
Certificate-aware handling of key fingerprints. OpenSSH, when called on to give the fingerprint of a certified public key, will in many circumstances generate the hash of the public blob of the _underlying_ key, rather than the hash of the full certificate. I think the hash of the certificate is also potentially useful (if nothing else, it provides a way to tell apart multiple certificates on the same key). But I can also see that it's useful to be able to recognise a key as the same one 'really' (since all certificates on the same key share a private key, so they're unavoidably related). So I've dealt with this by introducing an extra pair of fingerprint types, giving the cross product of {MD5, SHA-256} x {base key only, full certificate}. You can manually select which one you want to see in some circumstances (notably PuTTYgen), and in others (such as diagnostics) both fingerprints will be emitted side by side via the new functions ssh2_double_fingerprint[_blob]. The default, following OpenSSH, is to just fingerprint the base key.
2022-08-05 17:08:59 +00:00
char *fingerprint = ssh2_double_fingerprint_blob(
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
ptrlen_from_strbuf(pub->full_pub),
Refactor pageant_nth_ssh*_key. I've merged the two previous functions, with different return types per SSH version, into a single one that returns the containing PageantKey instead of pulling out one of its internal fields. This actually fixes a bug, though it would only have come up in the Unix Pageant debugging mode: an encrypted-only key would have terminated the key list in the diagnostic messages, because pageant_nth_ssh2_key would have returned pk->skey which was NULL. Now it returns pk itself, which isn't.
2021-04-02 10:42:17 +00:00
SSH_FPTYPE_DEFAULT);
Pageant: new PuTTY-specific ext request, 'list-extended'. This is an extended version of SSH2_AGENTC_REQUEST_IDENTITIES, which augments each entry in the returned key list with an extra field containing additional data about the key. The initial contents of that extra field are a pair of flags indicating whether the key is currently stored in the agent encrypted, decrypted or both. The idea is that this will permit a Pageant-aware client to make decisions based on that. For a start, the output key list can mention it to the user; also, if you try to add a key unencrypted when it's already present, we can discriminate based on whether it's already present _unencrypted_
2020-12-15 13:25:45 +00:00
pageant_client_log(pc, reqid, "returned key: %s %s",
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
fingerprint, pub->comment);
Pageant: new PuTTY-specific ext request, 'list-extended'. This is an extended version of SSH2_AGENTC_REQUEST_IDENTITIES, which augments each entry in the returned key list with an extra field containing additional data about the key. The initial contents of that extra field are a pair of flags indicating whether the key is currently stored in the agent encrypted, decrypted or both. The idea is that this will permit a Pageant-aware client to make decisions based on that. For a start, the output key list can mention it to the user; also, if you try to add a key unencrypted when it's already present, we can discriminate based on whether it's already present _unencrypted_
2020-12-15 13:25:45 +00:00
sfree(fingerprint);
}
}
break;
}
Pageant core: initial deferred decryption facility. This adds an extension request to the agent protocol (named in our private namespace, naturally) which allows you to upload a key file in the form of a string containing an entire .ppk file. If the key is encrypted, then Pageant stores it in such a way that it will show up in the key list, and on the first attempt to sign something with it, prompt for a passphrase (if it can), decrypt the key, and then answer the request. There are a lot of rough edges still to deal with, but this is good enough to have successfully answered one request, so it's a start.
2020-01-07 19:56:47 +00:00
}
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
default:
Pageant: new asynchronous internal APIs. This is a pure refactoring: no functional change expected. This commit introduces two new small vtable-style APIs. One is PageantClient, which identifies a particular client of the Pageant 'core' (meaning the code that handles each individual request). This changes pageant_handle_msg into an asynchronous operation: you pass in an agent request message and an identifier, and at some later point, the got_response method in your PageantClient will be called with the answer (and the same identifier, to allow you to match requests to responses). The trait vtable also contains a logging system. The main importance of PageantClient, and the reason why it has to exist instead of just passing pageant_handle_msg a bare callback function pointer and context parameter, is that it provides robustness if a client stops existing while a request is still pending. You call pageant_unregister_client, and any unfinished requests associated with that client in the Pageant core will be cleaned up, so that you're guaranteed that after the unregister operation, no stray callbacks will happen with a stale pointer to that client. The WM_COPYDATA interface of Windows Pageant is a direct client of this API. The other client is PageantListener, the system that lives in pageant.c and handles stream-based agent connections for both Unix Pageant and the new Windows named-pipe IPC. More specifically, each individual connection to the listening socket is a separate PageantClient, which means that if a socket is closed abruptly or suffers an OS error, that client can be unregistered and any pending requests cancelled without disrupting other connections. Users of PageantListener have a second client vtable they can use, called PageantListenerClient. That contains _only_ logging facilities, and at the moment, only Unix Pageant bothers to use it (and even that only in debugging mode). Finally, internally to the Pageant core, there's a new trait called PageantAsyncOp which describes an agent request in the process of being handled. But at the moment, it has only one trivial implementation, which is handed the full response message already constructed, and on the next toplevel callback, passes it back to the PageantClient.
2020-01-25 17:24:28 +00:00
pageant_client_log(pc, reqid, "request: unknown message type %d",
type);
Pageant: handle agent extension messages more correctly. Reading draft-miller-ssh-agent-04 more carefully, I see that I missed a few things from the extension-message spec. Firstly, there's an extension request "query" which is supposed to list all the extensions you support. Secondly, if you recognise an extension-request name but are then unable to fulfill the request for some other reason, you're supposed to return a new kind of failure message that's distinct from SSH_AGENT_FAILURE, because for extensions, the latter is reserved for "I don't even know what this extension name means at all". I've fixed both of those bugs in Pageant by making a centralised map of known extension names to an enumeration of internal ids, and an array containing the name for each id. So we can reliably answer the "query" extension by iterating over that array, and also use the same array to recognise known extensions up front and give them centralised processing (in particular, resetting the failure-message type) before switching on the particular extension index.
2020-02-10 20:45:31 +00:00
fail("unrecognised message");
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
break;
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
}
Pageant: handle agent extension messages more correctly. Reading draft-miller-ssh-agent-04 more carefully, I see that I missed a few things from the extension-message spec. Firstly, there's an extension request "query" which is supposed to list all the extensions you support. Secondly, if you recognise an extension-request name but are then unable to fulfill the request for some other reason, you're supposed to return a new kind of failure message that's distinct from SSH_AGENT_FAILURE, because for extensions, the latter is reserved for "I don't even know what this extension name means at all". I've fixed both of those bugs in Pageant by making a centralised map of known extension names to an enumeration of internal ids, and an array containing the name for each id. So we can reliably answer the "query" extension by iterating over that array, and also use the same array to recognise known extensions up front and give them centralised processing (in particular, resetting the failure-message type) before switching on the particular extension index.
2020-02-10 20:45:31 +00:00
#undef fail
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
responded:;
PageantImmOp *io = snew(PageantImmOp);
io->pao.vt = &immop_vtable;
io->pao.info = pc->info;
io->pao.cr.prev = pc->info->head.prev;
io->pao.cr.next = &pc->info->head;
Pageant: actually link requests on to their queues. When I create any class that implements PageantAsyncOp, I had intended to link its pao.cr list node on to the list in the appropriate PageantClientInfo, so that if that PageantClientInfo was destroyed prematurely (e.g. an agent connection was abruptly closed), we could destroy all the pending requests containing a pointer to it. I did this linking by setting the linked-list fields in pao.cr to point to the appropriate places in the existing list - but I didn't modify the pointer fields _in_ the existing list to point to the new operation at all. So nothing ever actually got linked on to any of those queues!
2021-09-30 17:56:26 +00:00
io->pao.cr.prev->next = io->pao.cr.next->prev = &io->pao.cr;
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
io->pao.reqid = reqid;
io->response = sb;
io->crLine = 0;
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
return &io->pao;
}
void pageant_handle_msg(PageantClient *pc, PageantClientRequestId *reqid,
ptrlen msgpl)
{
PageantAsyncOp *pao = pageant_make_op(pc, reqid, msgpl);
queue_toplevel_callback(pageant_async_op_callback, pao);
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
}
void pageant_init(void)
{
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_local = true;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
pubkeytree = newtree234(pubkey_cmpfn);
privkeytree = newtree234(privkey_cmpfn);
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
}
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
static PageantPublicKey *pageant_nth_pubkey(int ssh_version, int i)
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub = index234(
pubkeytree, find_first_pubkey_for_version(ssh_version) + i);
if (pub && pub->sort.priv.ssh_version == ssh_version)
return pub;
Rework Pageant to keep all keys in one big tree. I think this is on balance a cleanup in its own right. But the main purpose is that now Pageant has its own struct that wraps the RSAKey and ssh2_userkey objects it gets from the rest of the code. So I'll be able to put extra Pageant-specific data in that struct in future.
2020-01-06 20:59:07 +00:00
else
return NULL;
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
}
winpgnt: fix GUI removal of encrypted keys. The GUI loop that responded to the 'Remove Key' button in the key list worked by actually trying to retrieve a pointer to the ssh_key for a stored key, and then passing that back to the delete function. But when a key is encrypted, that pointer is NULL, so we segfaulted. Fixed by changing pageant_delete_ssh2_key() to take a numeric index in the list instead of a key pointer.
2021-04-02 10:30:18 +00:00
bool pageant_delete_nth_ssh1_key(int i)
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub = del_pubkey_pos(
find_first_pubkey_for_version(1) + i);
if (!pub)
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;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
pk_pub_free(pub);
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;
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
}
winpgnt: fix GUI removal of encrypted keys. The GUI loop that responded to the 'Remove Key' button in the key list worked by actually trying to retrieve a pointer to the ssh_key for a stored key, and then passing that back to the delete function. But when a key is encrypted, that pointer is NULL, so we segfaulted. Fixed by changing pageant_delete_ssh2_key() to take a numeric index in the list instead of a key pointer.
2021-04-02 10:30:18 +00:00
bool pageant_delete_nth_ssh2_key(int i)
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub = del_pubkey_pos(
find_first_pubkey_for_version(2) + i);
if (!pub)
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;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
pk_pub_free(pub);
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;
Move half of Pageant out into a cross-platform source file. I'm aiming for windows/winpgnt.c to only contain the parts of Windows Pageant that are actually to do with handling the Windows API, and for all the actual agent logic to be cross-platform. This commit is a start: I've moved every function and internal variable that was easy to move. But it doesn't get all the way there - there's still a lot of logic in add_keyfile() and get_keylist*() that would be good to move out to cross-platform code, but it's harder because that code is currently quite intertwined with details of Windows OS interfacing such as printing message boxes and passphrase prompts and calling back out to agent_query if the Pageant doing that job isn't the primary one.
2015-05-05 19:16:19 +00:00
}
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
winpgnt: add GUI button to re-encrypt an SSH-2 key.
2021-04-04 08:42:00 +00:00
bool pageant_reencrypt_nth_ssh2_key(int i)
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub = index234(
pubkeytree, find_first_pubkey_for_version(2) + i);
if (!pub)
winpgnt: add GUI button to re-encrypt an SSH-2 key.
2021-04-04 08:42:00 +00:00
return false;
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
return reencrypt_key(pub);
winpgnt: add GUI button to re-encrypt an SSH-2 key.
2021-04-04 08:42:00 +00:00
}
winpgnt: menu options to delete/reencrypt everything. Now the systray menu includes 'Remove All Keys' and 'Re-encrypt All Keys' options, which do exactly what they say on the tin.
2021-04-04 09:02:24 +00:00
void pageant_delete_all(void)
{
remove_all_keys(1);
remove_all_keys(2);
}
void pageant_reencrypt_all(void)
{
Pageant core: separate public and private key storage. Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.)
2022-08-06 09:41:41 +00:00
PageantPublicKey *pub;
for (int i = 0; (pub = index234(pubkeytree, i)) != NULL; i++)
reencrypt_key(pub);
winpgnt: menu options to delete/reencrypt everything. Now the systray menu includes 'Remove All Keys' and 'Re-encrypt All Keys' options, which do exactly what they say on the tin.
2021-04-04 09:02:24 +00:00
}
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
/* ----------------------------------------------------------------------
* The agent plug.
*/
/*
Remove duplicate coroutine macros. pageant.c and sshshare.c each had an extra copy of crBegin and crFinishV, dating from when the main versions were kept in ssh.c where they couldn't be conveniently #included by other modules. Now they're in sshcr.h, where they can be, so there's no need to have extra copies of them anywhere. (But I've left the crGetChar macro in each of those files, because those really are specific to the particular context, referring to an extra variable that clients of the more general sshcr.h macros won't all have.)
2019-02-28 18:05:38 +00:00
* An extra coroutine macro, specific to this code which is consuming
* 'const char *data'.
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
*/
#define crGetChar(c) do \
{ \
while (len == 0) { \
Make plug receive and closing functions return void instead of int. Nothing was paying attention to their return values any more anyway.
2016-06-02 22:03:24 +00:00
*crLine =__LINE__; return; case __LINE__:; \
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
} \
len--; \
(c) = (unsigned char)*data++; \
} while (0)
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 pageant_conn_queued_response {
struct pageant_conn_queued_response *next, *prev;
size_t req_index; /* for indexing requests in log messages */
strbuf *sb;
PageantClientRequestId reqid;
};
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
struct pageant_conn_state {
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 *connsock;
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;
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
unsigned char lenbuf[4], pktbuf[AGENT_MAX_MSGLEN];
unsigned len, got;
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 real_packet;
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
size_t conn_index; /* for indexing connections in log messages */
size_t req_index; /* for indexing requests in log messages */
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
int crLine; /* for coroutine in pageant_conn_receive */
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
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 pageant_conn_queued_response response_queue;
PageantClient pc;
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;
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
};
New API for plug_closing() with a custom type enum. Passing an operating-system-specific error code to plug_closing(), such as errno or GetLastError(), was always a bit weird, given that it generally had to be handled by cross-platform receiving code in backends. I had the platform.h implementations #define any error values that the cross-platform code would have to handle specially, but that's still not a great system, because it also doesn't leave freedom to invent error representations of my own that don't correspond to any OS code. (For example, the ones I just removed from proxy.h.) So now, the OS error code is gone from the plug_closing API, and in its place is a custom enumeration of closure types: normal, error, and the special case BROKEN_PIPE which is the only OS error code we have so far needed to handle specially. (All others just mean 'abandon the connection and print the textual message'.) Having already centralised the handling of OS error codes in the previous commit, we've now got a convenient place to add any further type codes for errors needing special handling: each of Unix plug_closing_errno(), Windows plug_closing_system_error(), and Windows plug_closing_winsock_error() can easily grow extra special cases if need be, and each one will only have to live in one place.
2021-11-06 13:28:32 +00:00
static void pageant_conn_closing(Plug *plug, PlugCloseType type,
const char *error_msg)
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
struct pageant_conn_state *pc = container_of(
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, struct pageant_conn_state, plug);
New API for plug_closing() with a custom type enum. Passing an operating-system-specific error code to plug_closing(), such as errno or GetLastError(), was always a bit weird, given that it generally had to be handled by cross-platform receiving code in backends. I had the platform.h implementations #define any error values that the cross-platform code would have to handle specially, but that's still not a great system, because it also doesn't leave freedom to invent error representations of my own that don't correspond to any OS code. (For example, the ones I just removed from proxy.h.) So now, the OS error code is gone from the plug_closing API, and in its place is a custom enumeration of closure types: normal, error, and the special case BROKEN_PIPE which is the only OS error code we have so far needed to handle specially. (All others just mean 'abandon the connection and print the textual message'.) Having already centralised the handling of OS error codes in the previous commit, we've now got a convenient place to add any further type codes for errors needing special handling: each of Unix plug_closing_errno(), Windows plug_closing_system_error(), and Windows plug_closing_winsock_error() can easily grow extra special cases if need be, and each one will only have to live in one place.
2021-11-06 13:28:32 +00:00
if (type != PLUGCLOSE_NORMAL)
New wrapper macro for printf("%zu"), for old VS compat. A user reports that Visual Studio 2013 and earlier have printf implementations in their C library that don't support the 'z' modifier to indicate that an integer argument is size_t. The 'I' modifier apparently works in place of it. To avoid littering ifdefs everywhere, I've invented my own inttypes.h style macros to wrap size_t formatting directives, which are defined to %zu and %zx normally, or %Iu and %Ix in old-VS mode. Those are in defs.h, and they're used everywhere that a %z might otherwise get into the Windows build.
2020-01-26 10:59:07 +00:00
pageant_listener_client_log(pc->plc, "c#%"SIZEu": error: %s",
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
pc->conn_index, error_msg);
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
else
New wrapper macro for printf("%zu"), for old VS compat. A user reports that Visual Studio 2013 and earlier have printf implementations in their C library that don't support the 'z' modifier to indicate that an integer argument is size_t. The 'I' modifier apparently works in place of it. To avoid littering ifdefs everywhere, I've invented my own inttypes.h style macros to wrap size_t formatting directives, which are defined to %zu and %zx normally, or %Iu and %Ix in old-VS mode. Those are in defs.h, and they're used everywhere that a %z might otherwise get into the Windows build.
2020-01-26 10:59:07 +00:00
pageant_listener_client_log(pc->plc, "c#%"SIZEu": connection closed",
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
pc->conn_index);
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
sk_close(pc->connsock);
Pageant: new asynchronous internal APIs. This is a pure refactoring: no functional change expected. This commit introduces two new small vtable-style APIs. One is PageantClient, which identifies a particular client of the Pageant 'core' (meaning the code that handles each individual request). This changes pageant_handle_msg into an asynchronous operation: you pass in an agent request message and an identifier, and at some later point, the got_response method in your PageantClient will be called with the answer (and the same identifier, to allow you to match requests to responses). The trait vtable also contains a logging system. The main importance of PageantClient, and the reason why it has to exist instead of just passing pageant_handle_msg a bare callback function pointer and context parameter, is that it provides robustness if a client stops existing while a request is still pending. You call pageant_unregister_client, and any unfinished requests associated with that client in the Pageant core will be cleaned up, so that you're guaranteed that after the unregister operation, no stray callbacks will happen with a stale pointer to that client. The WM_COPYDATA interface of Windows Pageant is a direct client of this API. The other client is PageantListener, the system that lives in pageant.c and handles stream-based agent connections for both Unix Pageant and the new Windows named-pipe IPC. More specifically, each individual connection to the listening socket is a separate PageantClient, which means that if a socket is closed abruptly or suffers an OS error, that client can be unregistered and any pending requests cancelled without disrupting other connections. Users of PageantListener have a second client vtable they can use, called PageantListenerClient. That contains _only_ logging facilities, and at the moment, only Unix Pageant bothers to use it (and even that only in debugging mode). Finally, internally to the Pageant core, there's a new trait called PageantAsyncOp which describes an agent request in the process of being handled. But at the moment, it has only one trivial implementation, which is handed the full response message already constructed, and on the next toplevel callback, passes it back to the PageantClient.
2020-01-25 17:24:28 +00:00
pageant_unregister_client(&pc->pc);
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
sfree(pc);
}
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 pageant_conn_sent(Plug *plug, size_t bufsize)
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
/* struct pageant_conn_state *pc = container_of(
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, struct pageant_conn_state, plug); */
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
/*
* We do nothing here, because we expect that there won't be a
* need to throttle and unthrottle the connection to an agent -
* clients will typically not send many requests, and will wait
* until they receive each reply before sending a new request.
*/
}
Pageant: new asynchronous internal APIs. This is a pure refactoring: no functional change expected. This commit introduces two new small vtable-style APIs. One is PageantClient, which identifies a particular client of the Pageant 'core' (meaning the code that handles each individual request). This changes pageant_handle_msg into an asynchronous operation: you pass in an agent request message and an identifier, and at some later point, the got_response method in your PageantClient will be called with the answer (and the same identifier, to allow you to match requests to responses). The trait vtable also contains a logging system. The main importance of PageantClient, and the reason why it has to exist instead of just passing pageant_handle_msg a bare callback function pointer and context parameter, is that it provides robustness if a client stops existing while a request is still pending. You call pageant_unregister_client, and any unfinished requests associated with that client in the Pageant core will be cleaned up, so that you're guaranteed that after the unregister operation, no stray callbacks will happen with a stale pointer to that client. The WM_COPYDATA interface of Windows Pageant is a direct client of this API. The other client is PageantListener, the system that lives in pageant.c and handles stream-based agent connections for both Unix Pageant and the new Windows named-pipe IPC. More specifically, each individual connection to the listening socket is a separate PageantClient, which means that if a socket is closed abruptly or suffers an OS error, that client can be unregistered and any pending requests cancelled without disrupting other connections. Users of PageantListener have a second client vtable they can use, called PageantListenerClient. That contains _only_ logging facilities, and at the moment, only Unix Pageant bothers to use it (and even that only in debugging mode). Finally, internally to the Pageant core, there's a new trait called PageantAsyncOp which describes an agent request in the process of being handled. But at the moment, it has only one trivial implementation, which is handed the full response message already constructed, and on the next toplevel callback, passes it back to the PageantClient.
2020-01-25 17:24:28 +00:00
static void pageant_conn_log(PageantClient *pc, PageantClientRequestId *reqid,
const char *fmt, va_list ap)
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
{
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 pageant_conn_state *pcs =
container_of(pc, struct pageant_conn_state, pc);
struct pageant_conn_queued_response *qr =
container_of(reqid, struct pageant_conn_queued_response, reqid);
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
char *formatted = dupvprintf(fmt, ap);
New wrapper macro for printf("%zu"), for old VS compat. A user reports that Visual Studio 2013 and earlier have printf implementations in their C library that don't support the 'z' modifier to indicate that an integer argument is size_t. The 'I' modifier apparently works in place of it. To avoid littering ifdefs everywhere, I've invented my own inttypes.h style macros to wrap size_t formatting directives, which are defined to %zu and %zx normally, or %Iu and %Ix in old-VS mode. Those are in defs.h, and they're used everywhere that a %z might otherwise get into the Windows build.
2020-01-26 10:59:07 +00:00
pageant_listener_client_log(pcs->plc, "c#%"SIZEu",r#%"SIZEu": %s",
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
pcs->conn_index, qr->req_index, formatted);
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
sfree(formatted);
}
Pageant: new asynchronous internal APIs. This is a pure refactoring: no functional change expected. This commit introduces two new small vtable-style APIs. One is PageantClient, which identifies a particular client of the Pageant 'core' (meaning the code that handles each individual request). This changes pageant_handle_msg into an asynchronous operation: you pass in an agent request message and an identifier, and at some later point, the got_response method in your PageantClient will be called with the answer (and the same identifier, to allow you to match requests to responses). The trait vtable also contains a logging system. The main importance of PageantClient, and the reason why it has to exist instead of just passing pageant_handle_msg a bare callback function pointer and context parameter, is that it provides robustness if a client stops existing while a request is still pending. You call pageant_unregister_client, and any unfinished requests associated with that client in the Pageant core will be cleaned up, so that you're guaranteed that after the unregister operation, no stray callbacks will happen with a stale pointer to that client. The WM_COPYDATA interface of Windows Pageant is a direct client of this API. The other client is PageantListener, the system that lives in pageant.c and handles stream-based agent connections for both Unix Pageant and the new Windows named-pipe IPC. More specifically, each individual connection to the listening socket is a separate PageantClient, which means that if a socket is closed abruptly or suffers an OS error, that client can be unregistered and any pending requests cancelled without disrupting other connections. Users of PageantListener have a second client vtable they can use, called PageantListenerClient. That contains _only_ logging facilities, and at the moment, only Unix Pageant bothers to use it (and even that only in debugging mode). Finally, internally to the Pageant core, there's a new trait called PageantAsyncOp which describes an agent request in the process of being handled. But at the moment, it has only one trivial implementation, which is handed the full response message already constructed, and on the next toplevel callback, passes it back to the PageantClient.
2020-01-25 17:24:28 +00:00
static void pageant_conn_got_response(
PageantClient *pc, PageantClientRequestId *reqid, ptrlen response)
{
struct pageant_conn_state *pcs =
container_of(pc, struct pageant_conn_state, pc);
struct pageant_conn_queued_response *qr =
container_of(reqid, struct pageant_conn_queued_response, reqid);
qr->sb = strbuf_new_nm();
put_stringpl(qr->sb, response);
while (pcs->response_queue.next != &pcs->response_queue &&
pcs->response_queue.next->sb) {
qr = pcs->response_queue.next;
sk_write(pcs->connsock, qr->sb->u, qr->sb->len);
qr->next->prev = qr->prev;
qr->prev->next = qr->next;
strbuf_free(qr->sb);
sfree(qr);
}
}
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 pageant_conn_ask_passphrase(
Polish up passphrase prompts for key decryption. Now Windows Pageant has two clearly distinct dialog boxes for requesting a key passphrase: one to use synchronously when the user has just used the 'Add Key' GUI action, and one to use asynchronously in response to an agent client's attempt to use a key that was loaded encrypted. Also fixed the wording in the asynchronous box: there were two copies of the 'enter passphrase' instruction, one from the dialog definition in pageant.rc file and one from the cross-platform pageant.c. Now pageant.c doesn't format a whole user-facing message any more: it leaves that to the platform front end to do it the way it wants. I've also added a call to SetForegroundWindow, to try to get the passphrase prompt into the foreground. In my experience this doesn't actually get it the keyboard focus, which I think is deliberate on Windows's part and there's nothing I can do about it. But at least the user should _see_ that the prompt is there, so they can focus it themself.
2021-04-02 09:49:18 +00:00
PageantClient *pc, PageantClientDialogId *dlgid, const char *comment)
Pageant: introduce an API for passphrase prompts. This begins to head towards the goal of storing a key file encrypted in Pageant, and decrypting it on demand via a GUI prompt the first time a client requests a signature from it. That won't be a facility available in all situations, so we have to be able to return failure from the prompt. More precisely, there are two versions of this API, one in PageantClient and one in PageantListenerClient: the stream implementation of PageantClient implements the former API and hands it off to the latter. Windows Pageant has to directly implement both (but they will end up funnelling to the same function within winpgnt.c). NFC: for the moment, the new API functions are never called, and every implementation of them returns failure.
2020-01-20 21:22:33 +00:00
{
struct pageant_conn_state *pcs =
container_of(pc, struct pageant_conn_state, pc);
Polish up passphrase prompts for key decryption. Now Windows Pageant has two clearly distinct dialog boxes for requesting a key passphrase: one to use synchronously when the user has just used the 'Add Key' GUI action, and one to use asynchronously in response to an agent client's attempt to use a key that was loaded encrypted. Also fixed the wording in the asynchronous box: there were two copies of the 'enter passphrase' instruction, one from the dialog definition in pageant.rc file and one from the cross-platform pageant.c. Now pageant.c doesn't format a whole user-facing message any more: it leaves that to the platform front end to do it the way it wants. I've also added a call to SetForegroundWindow, to try to get the passphrase prompt into the foreground. In my experience this doesn't actually get it the keyboard focus, which I think is deliberate on Windows's part and there's nothing I can do about it. But at least the user should _see_ that the prompt is there, so they can focus it themself.
2021-04-02 09:49:18 +00:00
return pageant_listener_client_ask_passphrase(pcs->plc, dlgid, comment);
Pageant: introduce an API for passphrase prompts. This begins to head towards the goal of storing a key file encrypted in Pageant, and decrypting it on demand via a GUI prompt the first time a client requests a signature from it. That won't be a facility available in all situations, so we have to be able to return failure from the prompt. More precisely, there are two versions of this API, one in PageantClient and one in PageantListenerClient: the stream implementation of PageantClient implements the former API and hands it off to the latter. Windows Pageant has to directly implement both (but they will end up funnelling to the same function within winpgnt.c). NFC: for the moment, the new API functions are never called, and every implementation of them returns failure.
2020-01-20 21:22:33 +00:00
}
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
static const PageantClientVtable pageant_connection_clientvt = {
.log = pageant_conn_log,
.got_response = pageant_conn_got_response,
.ask_passphrase = pageant_conn_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
};
Add some missing 'const'. plug_receive(), sftp_senddata() and handle_gotdata() in particular now take const pointers. Also fixed 'char *receive_data' in struct ProxySocket.
2019-02-06 20:18:19 +00:00
static void pageant_conn_receive(
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
Plug *plug, int urgent, const char *data, size_t len)
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
struct pageant_conn_state *pc = container_of(
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, struct pageant_conn_state, plug);
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
char c;
crBegin(pc->crLine);
while (len > 0) {
pc->got = 0;
while (pc->got < 4) {
crGetChar(c);
pc->lenbuf[pc->got++] = c;
}
Stop using unqualified {GET,PUT}_32BIT. Those were a reasonable abbreviation when the code almost never had to deal with little-endian numbers, but they've crept into enough places now (e.g. the ECC formatting) that I think I'd now prefer that every use of the integer read/write macros was clearly marked with its endianness. So all uses of GET_??BIT and PUT_??BIT are now qualified. The special versions in x11fwd.c, which used variable endianness because so does the X11 protocol, are suffixed _X11 to make that clear, and where that pushed line lengths over 80 characters I've taken the opportunity to name a local variable to remind me of what that extra parameter actually does.
2019-02-04 07:39:03 +00:00
pc->len = GET_32BIT_MSB_FIRST(pc->lenbuf);
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
pc->got = 0;
pc->real_packet = (pc->len < AGENT_MAX_MSGLEN-4);
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 pageant_conn_queued_response *qr =
snew(struct pageant_conn_queued_response);
qr->prev = pc->response_queue.prev;
qr->next = &pc->response_queue;
qr->prev->next = qr->next->prev = qr;
qr->sb = NULL;
qr->req_index = pc->req_index++;
}
if (!pc->real_packet) {
/*
* Send failure immediately, before consuming the packet
* data. That way we notify the client reasonably early
* even if the data channel has just started spewing
* nonsense.
*/
pageant_client_log(&pc->pc, &pc->response_queue.prev->reqid,
"early reply: SSH_AGENT_FAILURE "
"(overlong message, length %u)", pc->len);
static const unsigned char failure[] = { SSH_AGENT_FAILURE };
pageant_conn_got_response(&pc->pc, &pc->response_queue.prev->reqid,
make_ptrlen(failure, lenof(failure)));
}
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
while (pc->got < pc->len) {
crGetChar(c);
if (pc->real_packet)
pc->pktbuf[pc->got] = c;
pc->got++;
}
Pageant: new asynchronous internal APIs. This is a pure refactoring: no functional change expected. This commit introduces two new small vtable-style APIs. One is PageantClient, which identifies a particular client of the Pageant 'core' (meaning the code that handles each individual request). This changes pageant_handle_msg into an asynchronous operation: you pass in an agent request message and an identifier, and at some later point, the got_response method in your PageantClient will be called with the answer (and the same identifier, to allow you to match requests to responses). The trait vtable also contains a logging system. The main importance of PageantClient, and the reason why it has to exist instead of just passing pageant_handle_msg a bare callback function pointer and context parameter, is that it provides robustness if a client stops existing while a request is still pending. You call pageant_unregister_client, and any unfinished requests associated with that client in the Pageant core will be cleaned up, so that you're guaranteed that after the unregister operation, no stray callbacks will happen with a stale pointer to that client. The WM_COPYDATA interface of Windows Pageant is a direct client of this API. The other client is PageantListener, the system that lives in pageant.c and handles stream-based agent connections for both Unix Pageant and the new Windows named-pipe IPC. More specifically, each individual connection to the listening socket is a separate PageantClient, which means that if a socket is closed abruptly or suffers an OS error, that client can be unregistered and any pending requests cancelled without disrupting other connections. Users of PageantListener have a second client vtable they can use, called PageantListenerClient. That contains _only_ logging facilities, and at the moment, only Unix Pageant bothers to use it (and even that only in debugging mode). Finally, internally to the Pageant core, there's a new trait called PageantAsyncOp which describes an agent request in the process of being handled. But at the moment, it has only one trivial implementation, which is handed the full response message already constructed, and on the next toplevel callback, passes it back to the PageantClient.
2020-01-25 17:24:28 +00:00
if (pc->real_packet)
pageant_handle_msg(&pc->pc, &pc->response_queue.prev->reqid,
make_ptrlen(pc->pktbuf, pc->len));
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
}
Make plug receive and closing functions return void instead of int. Nothing was paying attention to their return values any more anyway.
2016-06-02 22:03:24 +00:00
crFinishV;
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
}
struct pageant_listen_state {
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 *listensock;
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;
size_t conn_index; /* for indexing connections in log messages */
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
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;
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
};
New API for plug_closing() with a custom type enum. Passing an operating-system-specific error code to plug_closing(), such as errno or GetLastError(), was always a bit weird, given that it generally had to be handled by cross-platform receiving code in backends. I had the platform.h implementations #define any error values that the cross-platform code would have to handle specially, but that's still not a great system, because it also doesn't leave freedom to invent error representations of my own that don't correspond to any OS code. (For example, the ones I just removed from proxy.h.) So now, the OS error code is gone from the plug_closing API, and in its place is a custom enumeration of closure types: normal, error, and the special case BROKEN_PIPE which is the only OS error code we have so far needed to handle specially. (All others just mean 'abandon the connection and print the textual message'.) Having already centralised the handling of OS error codes in the previous commit, we've now got a convenient place to add any further type codes for errors needing special handling: each of Unix plug_closing_errno(), Windows plug_closing_system_error(), and Windows plug_closing_winsock_error() can easily grow extra special cases if need be, and each one will only have to live in one place.
2021-11-06 13:28:32 +00:00
static void pageant_listen_closing(Plug *plug, PlugCloseType type,
const char *error_msg)
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
struct pageant_listen_state *pl = container_of(
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, struct pageant_listen_state, plug);
New API for plug_closing() with a custom type enum. Passing an operating-system-specific error code to plug_closing(), such as errno or GetLastError(), was always a bit weird, given that it generally had to be handled by cross-platform receiving code in backends. I had the platform.h implementations #define any error values that the cross-platform code would have to handle specially, but that's still not a great system, because it also doesn't leave freedom to invent error representations of my own that don't correspond to any OS code. (For example, the ones I just removed from proxy.h.) So now, the OS error code is gone from the plug_closing API, and in its place is a custom enumeration of closure types: normal, error, and the special case BROKEN_PIPE which is the only OS error code we have so far needed to handle specially. (All others just mean 'abandon the connection and print the textual message'.) Having already centralised the handling of OS error codes in the previous commit, we've now got a convenient place to add any further type codes for errors needing special handling: each of Unix plug_closing_errno(), Windows plug_closing_system_error(), and Windows plug_closing_winsock_error() can easily grow extra special cases if need be, and each one will only have to live in one place.
2021-11-06 13:28:32 +00:00
if (type != PLUGCLOSE_NORMAL)
Pageant: new asynchronous internal APIs. This is a pure refactoring: no functional change expected. This commit introduces two new small vtable-style APIs. One is PageantClient, which identifies a particular client of the Pageant 'core' (meaning the code that handles each individual request). This changes pageant_handle_msg into an asynchronous operation: you pass in an agent request message and an identifier, and at some later point, the got_response method in your PageantClient will be called with the answer (and the same identifier, to allow you to match requests to responses). The trait vtable also contains a logging system. The main importance of PageantClient, and the reason why it has to exist instead of just passing pageant_handle_msg a bare callback function pointer and context parameter, is that it provides robustness if a client stops existing while a request is still pending. You call pageant_unregister_client, and any unfinished requests associated with that client in the Pageant core will be cleaned up, so that you're guaranteed that after the unregister operation, no stray callbacks will happen with a stale pointer to that client. The WM_COPYDATA interface of Windows Pageant is a direct client of this API. The other client is PageantListener, the system that lives in pageant.c and handles stream-based agent connections for both Unix Pageant and the new Windows named-pipe IPC. More specifically, each individual connection to the listening socket is a separate PageantClient, which means that if a socket is closed abruptly or suffers an OS error, that client can be unregistered and any pending requests cancelled without disrupting other connections. Users of PageantListener have a second client vtable they can use, called PageantListenerClient. That contains _only_ logging facilities, and at the moment, only Unix Pageant bothers to use it (and even that only in debugging mode). Finally, internally to the Pageant core, there's a new trait called PageantAsyncOp which describes an agent request in the process of being handled. But at the moment, it has only one trivial implementation, which is handed the full response message already constructed, and on the next toplevel callback, passes it back to the PageantClient.
2020-01-25 17:24:28 +00:00
pageant_listener_client_log(pl->plc, "listening socket: error: %s",
error_msg);
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
sk_close(pl->listensock);
pl->listensock = NULL;
}
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 pageant_connection_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
.closing = pageant_conn_closing,
.receive = pageant_conn_receive,
.sent = pageant_conn_sent,
Make all Plugs have a log function, even if no-op. Commit 8f5e9a4f8dc796a introduced a segfault into both Windows Pageant and Windows connection sharing upstreams when they receive an incoming named-pipe connection. This occurs because the PlugVtables for those incoming connections had a null pointer in the 'log' field, because hitherto, only sockets involved with an outgoing connection expected to receive plug_log() notifications. But I added such a notification in make_handle_socket, forgetting that that function is used for both outgoing and incoming named-pipe connections (among other things). So now a Plug implementation that expects to be set up by the plug_accepting() method on a listener may still receive PLUGLOG_CONNECT_SUCCESS. I could fix that by adding a parameter to make_handle_socket telling it whether to send a notification, but that seems like more faff than is really needed. Simpler to make a rule that says _all_ Socket types must implement the log() method, even if only with a no-op function. We already have a no-op implementation of log(), in nullplug.c. So I've exposed that outside its module (in the same style as all the nullseat functions and so on), to make it really easy to add log() methods to PlugVtables that don't need one.
2021-09-15 12:48:30 +00:00
.log = nullplug_log,
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
};
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 int pageant_listen_accepting(Plug *plug,
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
accept_fn_t constructor, accept_ctx_t ctx)
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
struct pageant_listen_state *pl = container_of(
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, struct pageant_listen_state, plug);
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
struct pageant_conn_state *pc;
const char *err;
Improve sk_peer_info. Previously, it returned a human-readable string suitable for log files, which tried to say something useful about the remote end of a socket. Now it returns a whole SocketPeerInfo structure, of which that human-friendly log string is just one field, but also some of the same information - remote IP address and port, in particular - is provided in machine-readable form where it's available.
2018-10-18 19:06:42 +00:00
SocketPeerInfo *peerinfo;
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
pc = snew(struct pageant_conn_state);
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
pc->plug.vt = &pageant_connection_plugvt;
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
pc->pc.vt = &pageant_connection_clientvt;
pc->plc = pl->plc;
pc->response_queue.next = pc->response_queue.prev = &pc->response_queue;
pc->conn_index = pl->conn_index++;
pc->req_index = 0;
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
pc->crLine = 0;
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
pc->connsock = constructor(ctx, &pc->plug);
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
if ((err = sk_socket_error(pc->connsock)) != NULL) {
sk_close(pc->connsock);
sfree(pc);
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
return 1;
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
}
Use 'true' and 'false' in sk_set_frozen calls. Apparently a handful of calls to that particular function managed to miss my big-bang conversion to using bool where appropriate, and were still being called with constants 0 and 1.
2020-02-12 21:35:04 +00:00
sk_set_frozen(pc->connsock, false);
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
peerinfo = sk_peer_info(pc->connsock);
Improve sk_peer_info. Previously, it returned a human-readable string suitable for log files, which tried to say something useful about the remote end of a socket. Now it returns a whole SocketPeerInfo structure, of which that human-friendly log string is just one field, but also some of the same information - remote IP address and port, in particular - is provided in machine-readable form where it's available.
2018-10-18 19:06:42 +00:00
if (peerinfo && peerinfo->log_text) {
New wrapper macro for printf("%zu"), for old VS compat. A user reports that Visual Studio 2013 and earlier have printf implementations in their C library that don't support the 'z' modifier to indicate that an integer argument is size_t. The 'I' modifier apparently works in place of it. To avoid littering ifdefs everywhere, I've invented my own inttypes.h style macros to wrap size_t formatting directives, which are defined to %zu and %zx normally, or %Iu and %Ix in old-VS mode. Those are in defs.h, and they're used everywhere that a %z might otherwise get into the Windows build.
2020-01-26 10:59:07 +00:00
pageant_listener_client_log(pl->plc,
"c#%"SIZEu": new connection from %s",
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
pc->conn_index, peerinfo->log_text);
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
} else {
New wrapper macro for printf("%zu"), for old VS compat. A user reports that Visual Studio 2013 and earlier have printf implementations in their C library that don't support the 'z' modifier to indicate that an integer argument is size_t. The 'I' modifier apparently works in place of it. To avoid littering ifdefs everywhere, I've invented my own inttypes.h style macros to wrap size_t formatting directives, which are defined to %zu and %zx normally, or %Iu and %Ix in old-VS mode. Those are in defs.h, and they're used everywhere that a %z might otherwise get into the Windows build.
2020-01-26 10:59:07 +00:00
pageant_listener_client_log(pl->plc, "c#%"SIZEu": new connection",
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
pc->conn_index);
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
}
Improve sk_peer_info. Previously, it returned a human-readable string suitable for log files, which tried to say something useful about the remote end of a socket. Now it returns a whole SocketPeerInfo structure, of which that human-friendly log string is just one field, but also some of the same information - remote IP address and port, in particular - is provided in machine-readable form where it's available.
2018-10-18 19:06:42 +00:00
sk_free_peer_info(peerinfo);
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
Pageant: new asynchronous internal APIs. This is a pure refactoring: no functional change expected. This commit introduces two new small vtable-style APIs. One is PageantClient, which identifies a particular client of the Pageant 'core' (meaning the code that handles each individual request). This changes pageant_handle_msg into an asynchronous operation: you pass in an agent request message and an identifier, and at some later point, the got_response method in your PageantClient will be called with the answer (and the same identifier, to allow you to match requests to responses). The trait vtable also contains a logging system. The main importance of PageantClient, and the reason why it has to exist instead of just passing pageant_handle_msg a bare callback function pointer and context parameter, is that it provides robustness if a client stops existing while a request is still pending. You call pageant_unregister_client, and any unfinished requests associated with that client in the Pageant core will be cleaned up, so that you're guaranteed that after the unregister operation, no stray callbacks will happen with a stale pointer to that client. The WM_COPYDATA interface of Windows Pageant is a direct client of this API. The other client is PageantListener, the system that lives in pageant.c and handles stream-based agent connections for both Unix Pageant and the new Windows named-pipe IPC. More specifically, each individual connection to the listening socket is a separate PageantClient, which means that if a socket is closed abruptly or suffers an OS error, that client can be unregistered and any pending requests cancelled without disrupting other connections. Users of PageantListener have a second client vtable they can use, called PageantListenerClient. That contains _only_ logging facilities, and at the moment, only Unix Pageant bothers to use it (and even that only in debugging mode). Finally, internally to the Pageant core, there's a new trait called PageantAsyncOp which describes an agent request in the process of being handled. But at the moment, it has only one trivial implementation, which is handed the full response message already constructed, and on the next toplevel callback, passes it back to the PageantClient.
2020-01-25 17:24:28 +00:00
pageant_register_client(&pc->pc);
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
return 0;
}
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 pageant_listener_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
.closing = pageant_listen_closing,
.accepting = pageant_listen_accepting,
Make all Plugs have a log function, even if no-op. Commit 8f5e9a4f8dc796a introduced a segfault into both Windows Pageant and Windows connection sharing upstreams when they receive an incoming named-pipe connection. This occurs because the PlugVtables for those incoming connections had a null pointer in the 'log' field, because hitherto, only sockets involved with an outgoing connection expected to receive plug_log() notifications. But I added such a notification in make_handle_socket, forgetting that that function is used for both outgoing and incoming named-pipe connections (among other things). So now a Plug implementation that expects to be set up by the plug_accepting() method on a listener may still receive PLUGLOG_CONNECT_SUCCESS. I could fix that by adding a parameter to make_handle_socket telling it whether to send a notification, but that seems like more faff than is really needed. Simpler to make a rule that says _all_ Socket types must implement the log() method, even if only with a no-op function. We already have a no-op implementation of log(), in nullplug.c. So I've exposed that outside its module (in the same style as all the nullseat functions and so on), to make it really easy to add log() methods to PlugVtables that don't need one.
2021-09-15 12:48:30 +00:00
.log = nullplug_log,
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
};
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
Pageant: new asynchronous internal APIs. This is a pure refactoring: no functional change expected. This commit introduces two new small vtable-style APIs. One is PageantClient, which identifies a particular client of the Pageant 'core' (meaning the code that handles each individual request). This changes pageant_handle_msg into an asynchronous operation: you pass in an agent request message and an identifier, and at some later point, the got_response method in your PageantClient will be called with the answer (and the same identifier, to allow you to match requests to responses). The trait vtable also contains a logging system. The main importance of PageantClient, and the reason why it has to exist instead of just passing pageant_handle_msg a bare callback function pointer and context parameter, is that it provides robustness if a client stops existing while a request is still pending. You call pageant_unregister_client, and any unfinished requests associated with that client in the Pageant core will be cleaned up, so that you're guaranteed that after the unregister operation, no stray callbacks will happen with a stale pointer to that client. The WM_COPYDATA interface of Windows Pageant is a direct client of this API. The other client is PageantListener, the system that lives in pageant.c and handles stream-based agent connections for both Unix Pageant and the new Windows named-pipe IPC. More specifically, each individual connection to the listening socket is a separate PageantClient, which means that if a socket is closed abruptly or suffers an OS error, that client can be unregistered and any pending requests cancelled without disrupting other connections. Users of PageantListener have a second client vtable they can use, called PageantListenerClient. That contains _only_ logging facilities, and at the moment, only Unix Pageant bothers to use it (and even that only in debugging mode). Finally, internally to the Pageant core, there's a new trait called PageantAsyncOp which describes an agent request in the process of being handled. But at the moment, it has only one trivial implementation, which is handed the full response message already constructed, and on the next toplevel callback, passes it back to the PageantClient.
2020-01-25 17:24:28 +00:00
struct pageant_listen_state *pageant_listener_new(
Plug **plug, PageantListenerClient *plc)
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
{
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
struct pageant_listen_state *pl = snew(struct pageant_listen_state);
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
pl->plug.vt = &pageant_listener_plugvt;
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->plc = plc;
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
pl->listensock = NULL;
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->conn_index = 0;
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 = &pl->plug;
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
return 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
void pageant_listener_got_socket(struct pageant_listen_state *pl, Socket *sock)
Cross-platform support for speaking SSH agent protocol on a Socket. The exact nature of the Socket is left up to the front end to decide, so that we can use a Unix-domain socket on Unix and a Windows named pipe on Windows. But the logic of how we receive data and what we send in response is all cross-platform.
2015-05-05 19:16:20 +00:00
{
pl->listensock = sock;
}
void pageant_listener_free(struct pageant_listen_state *pl)
{
if (pl->listensock)
sk_close(pl->listensock);
sfree(pl);
}
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
/* ----------------------------------------------------------------------
* Code to perform agent operations either as a client, or within the
* same process as the running agent.
*/
static tree234 *passphrases = NULL;
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
typedef struct PageantInternalClient {
strbuf *response;
bool got_response;
PageantClient pc;
} PageantInternalClient;
static void internal_client_got_response(
PageantClient *pc, PageantClientRequestId *reqid, ptrlen response)
{
PageantInternalClient *pic = container_of(pc, PageantInternalClient, pc);
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
strbuf_clear(pic->response);
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
put_datapl(pic->response, response);
pic->got_response = true;
}
static bool internal_client_ask_passphrase(
Polish up passphrase prompts for key decryption. Now Windows Pageant has two clearly distinct dialog boxes for requesting a key passphrase: one to use synchronously when the user has just used the 'Add Key' GUI action, and one to use asynchronously in response to an agent client's attempt to use a key that was loaded encrypted. Also fixed the wording in the asynchronous box: there were two copies of the 'enter passphrase' instruction, one from the dialog definition in pageant.rc file and one from the cross-platform pageant.c. Now pageant.c doesn't format a whole user-facing message any more: it leaves that to the platform front end to do it the way it wants. I've also added a call to SetForegroundWindow, to try to get the passphrase prompt into the foreground. In my experience this doesn't actually get it the keyboard focus, which I think is deliberate on Windows's part and there's nothing I can do about it. But at least the user should _see_ that the prompt is there, so they can focus it themself.
2021-04-02 09:49:18 +00:00
PageantClient *pc, PageantClientDialogId *dlgid, const char *comment)
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
{
/* No delaying operations are permitted in this mode */
return false;
}
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
static const PageantClientVtable internal_clientvt = {
.log = NULL,
.got_response = internal_client_got_response,
.ask_passphrase = internal_client_ask_passphrase,
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
};
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
typedef struct PageantClientOp {
strbuf *buf;
bool request_made;
BinarySink_DELEGATE_IMPLEMENTATION;
BinarySource_IMPLEMENTATION;
} PageantClientOp;
static PageantClientOp *pageant_client_op_new(void)
{
PageantClientOp *pco = snew(PageantClientOp);
pco->buf = strbuf_new_for_agent_query();
pco->request_made = false;
BinarySink_DELEGATE_INIT(pco, pco->buf);
BinarySource_INIT(pco, "", 0);
return pco;
}
static void pageant_client_op_free(PageantClientOp *pco)
{
if (pco->buf)
strbuf_free(pco->buf);
sfree(pco);
}
static unsigned pageant_client_op_query(PageantClientOp *pco)
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
{
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
/* Since we use the same strbuf for the request and the response,
* check by assertion that we aren't embarrassingly sending a
* previous response back to the agent */
assert(!pco->request_made);
pco->request_made = true;
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
if (!pageant_local) {
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
void *response_raw;
int resplen_raw;
agent_query_synchronous(pco->buf, &response_raw, &resplen_raw);
strbuf_clear(pco->buf);
put_data(pco->buf, response_raw, resplen_raw);
sfree(response_raw);
/* The data coming back from agent_query_synchronous will have
* its length field prepended. So we start by parsing it as an
* SSH-formatted string, and then reinitialise our
* BinarySource with the interior of that string. */
BinarySource_INIT_PL(pco, ptrlen_from_strbuf(pco->buf));
BinarySource_INIT_PL(pco, get_string(pco));
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
} else {
PageantInternalClient pic;
PageantClientRequestId reqid;
pic.pc.vt = &internal_clientvt;
pic.pc.suppress_logging = true;
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
pic.response = pco->buf;
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
pic.got_response = false;
pageant_register_client(&pic.pc);
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
assert(pco->buf->len > 4);
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
PageantAsyncOp *pao = pageant_make_op(
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
&pic.pc, &reqid, make_ptrlen(pco->buf->s + 4, pco->buf->len - 4));
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
while (!pic.got_response)
pageant_async_op_coroutine(pao);
pageant_unregister_client(&pic.pc);
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
BinarySource_INIT_PL(pco, ptrlen_from_strbuf(pco->buf));
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
}
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
/* Strip off and directly return the type byte, which every client
* will need, to save a boilerplate get_byte at each call site */
unsigned reply_type = get_byte(pco);
if (get_err(pco))
reply_type = 256; /* out-of-range code */
return reply_type;
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
}
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
/*
* After processing a list of filenames, we want to forget the
* passphrases.
*/
void pageant_forget_passphrases(void)
{
Add a check for NULL in pageant_forget_passphrases(). I've no reason to believe it will _currently_ be called with the 'passphrases' tree not even set up yet, but I managed to get that to happen while playing about with experimental code just now, and it seemed like a good safety check to keep in general.
2015-05-14 08:16:26 +00:00
if (!passphrases) /* in case we never set it up at all */
return;
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
while (count234(passphrases) > 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 *pp = index234(passphrases, 0);
smemclr(pp, strlen(pp));
delpos234(passphrases, 0);
sfree(pp);
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
}
}
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
typedef struct KeyListEntry {
ptrlen blob, comment;
pageant_get_keylist: use the new extended list if available. Now the returned list of keys will have a flags word for each key, if the agent was willing to provide one.
2020-12-15 13:40:51 +00:00
uint32_t flags;
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
} KeyListEntry;
typedef struct KeyList {
strbuf *raw_data;
KeyListEntry *keys;
size_t nkeys;
bool broken;
} KeyList;
static void keylist_free(KeyList *kl)
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
{
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
sfree(kl->keys);
strbuf_free(kl->raw_data);
sfree(kl);
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
}
pageant_get_keylist: use the new extended list if available. Now the returned list of keys will have a flags word for each key, if the agent was willing to provide one.
2020-12-15 13:40:51 +00:00
static PageantClientOp *pageant_request_keylist_1(void)
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
{
pageant_get_keylist: use the new extended list if available. Now the returned list of keys will have a flags word for each key, if the agent was willing to provide one.
2020-12-15 13:40:51 +00:00
PageantClientOp *pco = pageant_client_op_new();
put_byte(pco, SSH1_AGENTC_REQUEST_RSA_IDENTITIES);
if (pageant_client_op_query(pco) == SSH1_AGENT_RSA_IDENTITIES_ANSWER)
return pco;
pageant_client_op_free(pco);
return NULL;
}
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
pageant_get_keylist: use the new extended list if available. Now the returned list of keys will have a flags word for each key, if the agent was willing to provide one.
2020-12-15 13:40:51 +00:00
static PageantClientOp *pageant_request_keylist_2(void)
{
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
PageantClientOp *pco = pageant_client_op_new();
pageant_get_keylist: use the new extended list if available. Now the returned list of keys will have a flags word for each key, if the agent was willing to provide one.
2020-12-15 13:40:51 +00:00
put_byte(pco, SSH2_AGENTC_REQUEST_IDENTITIES);
if (pageant_client_op_query(pco) == SSH2_AGENT_IDENTITIES_ANSWER)
return pco;
pageant_client_op_free(pco);
return NULL;
}
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
pageant_get_keylist: use the new extended list if available. Now the returned list of keys will have a flags word for each key, if the agent was willing to provide one.
2020-12-15 13:40:51 +00:00
static PageantClientOp *pageant_request_keylist_extended(void)
{
PageantClientOp *pco = pageant_client_op_new();
put_byte(pco, SSH2_AGENTC_EXTENSION);
put_stringpl(pco, extension_names[EXT_LIST_EXTENDED]);
if (pageant_client_op_query(pco) == SSH_AGENT_SUCCESS)
return pco;
pageant_client_op_free(pco);
return NULL;
}
static KeyList *pageant_get_keylist(unsigned ssh_version)
{
PageantClientOp *pco;
bool list_is_extended = false;
if (ssh_version == 1) {
pco = pageant_request_keylist_1();
} else {
if ((pco = pageant_request_keylist_extended()) != NULL)
list_is_extended = true;
else
pco = pageant_request_keylist_2();
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
}
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
pageant_get_keylist: use the new extended list if available. Now the returned list of keys will have a flags word for each key, if the agent was willing to provide one.
2020-12-15 13:40:51 +00:00
if (!pco)
return NULL;
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
KeyList *kl = snew(KeyList);
kl->nkeys = get_uint32(pco);
kl->keys = snewn(kl->nkeys, struct KeyListEntry);
pageant_get_keylist: add missing init of kl->broken. In commit d53b3bcd22ace906 I changed the final setting of kl->broken so that it wouldn't overwrite a 'true' value set earlier in the function. But that means it might not be set at all, because I forgot I now needed to initialise it to false. Ahem.
2021-04-10 09:55:53 +00:00
kl->broken = false;
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
for (size_t i = 0; i < kl->nkeys && !get_err(pco); i++) {
if (ssh_version == 1) {
pageant_get_keylist: fix handling of bad SSH-1 data from agent. Coverity points out that if rsa_ssh1_public_blob_len sees data it doesn't like, it returns -1 to indicate an error. But the code that uses it to parse the SSH1_AGENT_RSA_IDENTITIES_ANSWER payload was passing it directly to get_data() as a length field, without checking for that case. Now we do check it, and use it to set the existing kl->broken flag that indicates that the key list was not correctly formatted.
2021-04-09 17:21:40 +00:00
int bloblen = rsa_ssh1_public_blob_len(
make_ptrlen(get_ptr(pco), get_avail(pco)));
if (bloblen < 0) {
kl->broken = true;
bloblen = 0;
}
kl->keys[i].blob = get_data(pco, bloblen);
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
} else {
kl->keys[i].blob = get_string(pco);
}
kl->keys[i].comment = get_string(pco);
pageant_get_keylist: use the new extended list if available. Now the returned list of keys will have a flags word for each key, if the agent was willing to provide one.
2020-12-15 13:40:51 +00:00
if (list_is_extended) {
ptrlen key_ext_info = get_string(pco);
BinarySource src[1];
BinarySource_BARE_INIT_PL(src, key_ext_info);
kl->keys[i].flags = get_uint32(src);
} else {
kl->keys[i].flags = 0;
}
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
}
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
pageant_get_keylist: fix handling of bad SSH-1 data from agent. Coverity points out that if rsa_ssh1_public_blob_len sees data it doesn't like, it returns -1 to indicate an error. But the code that uses it to parse the SSH1_AGENT_RSA_IDENTITIES_ANSWER payload was passing it directly to get_data() as a length field, without checking for that case. Now we do check it, and use it to set the existing kl->broken flag that indicates that the key list was not correctly formatted.
2021-04-09 17:21:40 +00:00
if (get_err(pco))
kl->broken = true;
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
kl->raw_data = pco->buf;
pco->buf = NULL;
pageant_client_op_free(pco);
return kl;
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
}
int pageant_add_keyfile(Filename *filename, const char *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
char **retstr, bool add_encrypted)
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
{
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 = NULL;
ssh2_userkey *skey = NULL;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool needs_pass;
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
int ret;
int attempts;
char *comment;
const char *this_passphrase;
const char *error = NULL;
int type;
if (!passphrases) {
passphrases = newtree234(NULL);
}
*retstr = NULL;
type = key_type(filename);
if (type != SSH_KEYTYPE_SSH1 && type != SSH_KEYTYPE_SSH2) {
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
*retstr = dupprintf("Couldn't load this key (%s)",
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
key_type_to_str(type));
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
return PAGEANT_ACTION_FAILURE;
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +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
if (add_encrypted && type == SSH_KEYTYPE_SSH1) {
*retstr = dupprintf("Can't add SSH-1 keys in encrypted form");
return PAGEANT_ACTION_FAILURE;
}
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
/*
* See if the key is already loaded (in the primary Pageant,
* which may or may not be us).
*/
{
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
strbuf *blob = strbuf_new();
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
KeyList *kl;
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
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
if (type == SSH_KEYTYPE_SSH1) {
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(filename, BinarySink_UPCAST(blob),
NULL, &error)) {
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
*retstr = dupprintf("Couldn't load private key (%s)", 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(blob);
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
return PAGEANT_ACTION_FAILURE;
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
}
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
kl = pageant_get_keylist(1);
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 {
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(filename, NULL, BinarySink_UPCAST(blob),
NULL, &error)) {
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
*retstr = dupprintf("Couldn't load private key (%s)", 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(blob);
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
return PAGEANT_ACTION_FAILURE;
}
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
kl = pageant_get_keylist(2);
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
}
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
if (kl) {
if (kl->broken) {
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
*retstr = dupstr("Received broken key list from agent");
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
keylist_free(kl);
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(blob);
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
return PAGEANT_ACTION_FAILURE;
}
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
for (size_t i = 0; i < kl->nkeys; i++) {
pageant -a: upload an unencrypted key alongside an encrypted one. Now, if you have a given key stored encrypted in your agent and you say 'pageant -a [same key]' (without -E), Pageant will notice (via the new extended key list request) that the key is currently encrypted in the agent, and that you're trying to add it unencrypted. In this situation it won't abort the attempt, and will try to add the key anyway, so that it becomes decrypted in your agent.
2020-12-15 13:46:39 +00:00
/*
Pageant: allow adding encrypted key to cleartext. The protocol already allowed adding an encrypted form to a cleartext key already held by the agent, and you might want to do so if, say, the key happened to originally be added in cleartext-only form but you want to be able to forget that with 'pageant -R' in future.
2021-04-05 14:07:09 +00:00
* If the key already exists in the agent, we're done,
* except in the following special cases:
pageant -a: upload an unencrypted key alongside an encrypted one. Now, if you have a given key stored encrypted in your agent and you say 'pageant -a [same key]' (without -E), Pageant will notice (via the new extended key list request) that the key is currently encrypted in the agent, and that you're trying to add it unencrypted. In this situation it won't abort the attempt, and will try to add the key anyway, so that it becomes decrypted in your agent.
2020-12-15 13:46:39 +00:00
*
Pageant: allow adding encrypted key to cleartext. The protocol already allowed adding an encrypted form to a cleartext key already held by the agent, and you might want to do so if, say, the key happened to originally be added in cleartext-only form but you want to be able to forget that with 'pageant -R' in future.
2021-04-05 14:07:09 +00:00
* It's encrypted in the agent, and we're being asked
* to add it unencrypted, in which case we still want
* to upload the unencrypted version to cause the key
* to become decrypted.
pageant -a: upload an unencrypted key alongside an encrypted one. Now, if you have a given key stored encrypted in your agent and you say 'pageant -a [same key]' (without -E), Pageant will notice (via the new extended key list request) that the key is currently encrypted in the agent, and that you're trying to add it unencrypted. In this situation it won't abort the attempt, and will try to add the key anyway, so that it becomes decrypted in your agent.
2020-12-15 13:46:39 +00:00
* (Rationale: if you know in advance you're going to
* want it, and don't want to be interrupted at an
* unpredictable moment to be asked for the
* passphrase.)
Pageant: allow adding encrypted key to cleartext. The protocol already allowed adding an encrypted form to a cleartext key already held by the agent, and you might want to do so if, say, the key happened to originally be added in cleartext-only form but you want to be able to forget that with 'pageant -R' in future.
2021-04-05 14:07:09 +00:00
*
* The agent only has cleartext, and we're being asked
* to add it encrypted, in which case we'll add the
* encrypted form.
* (Rationale: if you might want to re-encrypt the key
* at some future point, but it happened to have been
* initially added in cleartext, perhaps by something
* other than Pageant.)
pageant -a: upload an unencrypted key alongside an encrypted one. Now, if you have a given key stored encrypted in your agent and you say 'pageant -a [same key]' (without -E), Pageant will notice (via the new extended key list request) that the key is currently encrypted in the agent, and that you're trying to add it unencrypted. In this situation it won't abort the attempt, and will try to add the key anyway, so that it becomes decrypted in your agent.
2020-12-15 13:46:39 +00:00
*/
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
if (ptrlen_eq_ptrlen(ptrlen_from_strbuf(blob),
kl->keys[i].blob)) {
pageant -a: upload an unencrypted key alongside an encrypted one. Now, if you have a given key stored encrypted in your agent and you say 'pageant -a [same key]' (without -E), Pageant will notice (via the new extended key list request) that the key is currently encrypted in the agent, and that you're trying to add it unencrypted. In this situation it won't abort the attempt, and will try to add the key anyway, so that it becomes decrypted in your agent.
2020-12-15 13:46:39 +00:00
bool have_unencrypted =
!(kl->keys[i].flags &
LIST_EXTENDED_FLAG_HAS_NO_CLEARTEXT_KEY);
Pageant: allow adding encrypted key to cleartext. The protocol already allowed adding an encrypted form to a cleartext key already held by the agent, and you might want to do so if, say, the key happened to originally be added in cleartext-only form but you want to be able to forget that with 'pageant -R' in future.
2021-04-05 14:07:09 +00:00
bool have_encrypted =
(kl->keys[i].flags &
LIST_EXTENDED_FLAG_HAS_ENCRYPTED_KEY_FILE);
if ((have_unencrypted && !add_encrypted)
|| (have_encrypted && add_encrypted)) {
/* Key is already present in the desired form;
* we can now leave. */
pageant -a: upload an unencrypted key alongside an encrypted one. Now, if you have a given key stored encrypted in your agent and you say 'pageant -a [same key]' (without -E), Pageant will notice (via the new extended key list request) that the key is currently encrypted in the agent, and that you're trying to add it unencrypted. In this situation it won't abort the attempt, and will try to add the key anyway, so that it becomes decrypted in your agent.
2020-12-15 13:46:39 +00:00
keylist_free(kl);
strbuf_free(blob);
return PAGEANT_ACTION_OK;
}
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
}
}
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
keylist_free(kl);
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
}
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
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
strbuf_free(blob);
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +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
if (add_encrypted) {
const char *load_error;
LoadedFile *lf = lf_load_keyfile(filename, &load_error);
if (!lf) {
*retstr = dupstr(load_error);
return PAGEANT_ACTION_FAILURE;
}
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
PageantClientOp *pco = pageant_client_op_new();
put_byte(pco, SSH2_AGENTC_EXTENSION);
put_stringpl(pco, extension_names[EXT_ADD_PPK]);
put_string(pco, lf->data, lf->len);
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
lf_free(lf);
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
unsigned reply = pageant_client_op_query(pco);
pageant_client_op_free(pco);
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
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
if (reply != SSH_AGENT_SUCCESS) {
Pageant: Diagnose agent without protocol extensions. Gives more helpful messages if Unix pageant ends up being a client for, say, OpenSSH's ssh-agent, or indeed an older version of Pageant. (Also, tweak a couple of other messages that still assumed that pageant-as-client always talks to Pageant-as-agent.)
2021-04-05 14:20:25 +00:00
if (reply == SSH_AGENT_FAILURE) {
/* The agent didn't understand the protocol extension
* at all. */
*retstr = dupstr("Agent doesn't support adding "
"encrypted keys");
} else {
*retstr = dupstr("The already running agent "
"refused to add the key.");
}
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 PAGEANT_ACTION_FAILURE;
}
return PAGEANT_ACTION_OK;
}
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
error = NULL;
if (type == SSH_KEYTYPE_SSH1)
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
needs_pass = rsa1_encrypted_f(filename, &comment);
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
else
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
needs_pass = ppk_encrypted_f(filename, &comment);
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
attempts = 0;
if (type == SSH_KEYTYPE_SSH1)
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
rkey = snew(RSAKey);
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
/*
* Loop round repeatedly trying to load the key, until we either
* succeed, fail for some serious reason, or run out of
* passphrases to try.
*/
while (1) {
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
if (needs_pass) {
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
/*
* If we've been given a passphrase on input, try using
* it. Otherwise, try one from our tree234 of previously
* useful passphrases.
*/
if (passphrase) {
this_passphrase = (attempts == 0 ? passphrase : NULL);
} else {
this_passphrase = (const char *)index234(passphrases, attempts);
}
if (!this_passphrase) {
/*
* Run out of passphrases to try.
*/
*retstr = comment;
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
sfree(rkey);
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
return PAGEANT_ACTION_NEED_PP;
}
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
this_passphrase = "";
if (type == SSH_KEYTYPE_SSH1)
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
ret = rsa1_load_f(filename, rkey, this_passphrase, &error);
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 {
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
skey = ppk_load_f(filename, this_passphrase, &error);
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
if (skey == SSH2_WRONG_PASSPHRASE)
ret = -1;
else if (!skey)
ret = 0;
else
ret = 1;
}
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
if (ret == 0) {
/*
* Failed to load the key file, for some reason other than
* a bad passphrase.
*/
*retstr = dupstr(error);
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
sfree(rkey);
Fix miscellaneous minor memory leaks. All found by Coverity.
2019-05-04 15:19:13 +00:00
if (comment)
sfree(comment);
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
return PAGEANT_ACTION_FAILURE;
} else if (ret == 1) {
/*
* Successfully loaded the key file.
*/
break;
} else {
/*
* Passphrase wasn't right; go round again.
*/
attempts++;
}
}
/*
Spelling fixes (just in comments). As found by a bot ( http://www.misfix.org, https://github.com/ka7/misspell_fixer ).
2017-04-15 08:06:22 +00:00
* If we get here, we've successfully loaded the key into
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
* rkey/skey, but not yet added it to the agent.
*/
/*
* If the key was successfully decrypted, save the passphrase for
* use with other keys we try to load.
*/
{
char *pp_copy = dupstr(this_passphrase);
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
if (addpos234(passphrases, pp_copy, 0) != pp_copy) {
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
/* No need; it was already there. */
smemclr(pp_copy, strlen(pp_copy));
sfree(pp_copy);
}
}
if (comment)
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
sfree(comment);
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
if (type == SSH_KEYTYPE_SSH1) {
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
PageantClientOp *pco = pageant_client_op_new();
put_byte(pco, SSH1_AGENTC_ADD_RSA_IDENTITY);
rsa_ssh1_private_blob_agent(BinarySink_UPCAST(pco), rkey);
put_stringz(pco, rkey->comment);
unsigned reply = pageant_client_op_query(pco);
pageant_client_op_free(pco);
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
freersakey(rkey);
sfree(rkey);
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
if (reply != SSH_AGENT_SUCCESS) {
Pageant: Diagnose agent without protocol extensions. Gives more helpful messages if Unix pageant ends up being a client for, say, OpenSSH's ssh-agent, or indeed an older version of Pageant. (Also, tweak a couple of other messages that still assumed that pageant-as-client always talks to Pageant-as-agent.)
2021-04-05 14:20:25 +00:00
*retstr = dupstr("The already running agent "
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
"refused to add the key.");
return PAGEANT_ACTION_FAILURE;
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
}
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
} else {
PageantClientOp *pco = pageant_client_op_new();
put_byte(pco, SSH2_AGENTC_ADD_IDENTITY);
put_stringz(pco, ssh_key_ssh_id(skey->key));
ssh_key_openssh_blob(skey->key, BinarySink_UPCAST(pco));
put_stringz(pco, skey->comment);
unsigned reply = pageant_client_op_query(pco);
pageant_client_op_free(pco);
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
Minor memory leaks in Pageant client code.
2020-02-08 16:56:30 +00:00
sfree(skey->comment);
Simplify the Pageant internal client code. Until now, all the functions that have to work in both the Pageant server and a separate client process have been implemented by having two code paths for every request, one of which marshals an agent request and passes it to agent_query_synchronous, and the other just calls one of the internal functions in the Pageant core. This is already quite ugly, and it'll only get worse when I start adding more client requests. So here's a simplification: now, there's only one code path, and we _always_ marshal a wire-format agent request. When we're the same process as the Pageant server, we pass it to the actual message handler and let that decode it again, enforcing by assertion that it's not an asynchronous operation that's going to delay. This patch removes a layer of indentation from many functions in the Pageant client layer, so it's best viewed with whitespace ignored.
2020-02-08 16:36:55 +00:00
ssh_key_free(skey->key);
sfree(skey);
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
if (reply != SSH_AGENT_SUCCESS) {
Pageant: Diagnose agent without protocol extensions. Gives more helpful messages if Unix pageant ends up being a client for, say, OpenSSH's ssh-agent, or indeed an older version of Pageant. (Also, tweak a couple of other messages that still assumed that pageant-as-client always talks to Pageant-as-agent.)
2021-04-05 14:20:25 +00:00
*retstr = dupstr("The already running agent "
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
"refused to add the key.");
return PAGEANT_ACTION_FAILURE;
}
Pageant: factor out cross-platform parts of add_keyfile(). I've now centralised into pageant.c all the logic about trying to load keys of any type, with no passphrase or with the passphrases used in previous key-loading actions or with a new user-supplied passphrase, whether we're the main Pageant process ourself or are talking to another one as a client. The only part of that code remaining in winpgnt.c is the user interaction via dialog boxes, which of course is the part that will need to be done differently on other platforms.
2015-05-11 14:06:25 +00:00
}
return PAGEANT_ACTION_OK;
}
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
int pageant_enum_keys(pageant_key_enum_fn_t callback, void *callback_ctx,
char **retstr)
{
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
KeyList *kl1 = NULL, *kl2 = 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
struct pageant_pubkey cbkey;
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
int toret = PAGEANT_ACTION_FAILURE;
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
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
kl1 = pageant_get_keylist(1);
Pageant client: tolerate failure to list keys. This enables Pageant to act as a client for OpenSSH's agent, which nowadays refuses to respond to SSH1_AGENTC_REQUEST_RSA_IDENTITIES, or any other SSH1_AGENTC_* message. It now treats SSH_AGENT_FAILURE in response to either 'list identities' request the same as successfully receiving an empty list.
2020-03-03 21:44:19 +00:00
if (kl1 && kl1->broken) {
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
*retstr = dupstr("Received broken SSH-1 key list from agent");
goto out;
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
}
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
kl2 = pageant_get_keylist(2);
Pageant client: tolerate failure to list keys. This enables Pageant to act as a client for OpenSSH's agent, which nowadays refuses to respond to SSH1_AGENTC_REQUEST_RSA_IDENTITIES, or any other SSH1_AGENTC_* message. It now treats SSH_AGENT_FAILURE in response to either 'list identities' request the same as successfully receiving an empty list.
2020-03-03 21:44:19 +00:00
if (kl2 && kl2->broken) {
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
*retstr = dupstr("Received broken SSH-2 key list from agent");
goto out;
}
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 client: tolerate failure to list keys. This enables Pageant to act as a client for OpenSSH's agent, which nowadays refuses to respond to SSH1_AGENTC_REQUEST_RSA_IDENTITIES, or any other SSH1_AGENTC_* message. It now treats SSH_AGENT_FAILURE in response to either 'list identities' request the same as successfully receiving an empty list.
2020-03-03 21:44:19 +00:00
if (kl1) {
for (size_t i = 0; i < kl1->nkeys; i++) {
Utility function strbuf_dup. If you already have a string (of potentially-binary data) in the form of a ptrlen reference to somewhere else, and you want to keep a copy somewhere, it's useful to copy it into a strbuf. But it takes a couple of lines of faff to do that, and it's nicer to wrap that up into a tiny helper function. This commit adds that helper function strbuf_dup, and its non-movable sibling strbuf_dup_nm for secret data. Also, gone through the existing code and found a bunch of cases where this makes things less verbose.
2022-04-19 09:53:44 +00:00
cbkey.blob = strbuf_dup(kl1->keys[i].blob);
Pageant client: tolerate failure to list keys. This enables Pageant to act as a client for OpenSSH's agent, which nowadays refuses to respond to SSH1_AGENTC_REQUEST_RSA_IDENTITIES, or any other SSH1_AGENTC_* message. It now treats SSH_AGENT_FAILURE in response to either 'list identities' request the same as successfully receiving an empty list.
2020-03-03 21:44:19 +00:00
cbkey.comment = mkstr(kl1->keys[i].comment);
cbkey.ssh_version = 1;
/* Decode public blob into a key in order to fingerprint it */
RSAKey rkey;
memset(&rkey, 0, sizeof(rkey));
{
BinarySource src[1];
BinarySource_BARE_INIT_PL(src, kl1->keys[i].blob);
get_rsa_ssh1_pub(src, &rkey, RSA_SSH1_EXPONENT_FIRST);
if (get_err(src)) {
*retstr = dupstr(
"Received an invalid SSH-1 key from agent");
goto out;
}
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
}
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
char **fingerprints = rsa_ssh1_fake_all_fingerprints(&rkey);
Pageant client: tolerate failure to list keys. This enables Pageant to act as a client for OpenSSH's agent, which nowadays refuses to respond to SSH1_AGENTC_REQUEST_RSA_IDENTITIES, or any other SSH1_AGENTC_* message. It now treats SSH_AGENT_FAILURE in response to either 'list identities' request the same as successfully receiving an empty list.
2020-03-03 21:44:19 +00:00
freersakey(&rkey);
Pageant client code: parse replies using BinarySource. This affects both the client code used by Pageant itself, in pageant.c, and the client code in ssh.c used during SSH userauth.
2018-05-27 22:58:20 +00:00
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
callback(callback_ctx, fingerprints, cbkey.comment,
pageant -l: indicate whether keys are encrypted. The callback function to pageant_enum_keys now takes a flags parameter, which receives the flags word from the extended key list request, if available. (If not, then the flags word is passed as zero.) The only callback that uses this parameter is the one for printing text output from 'pageant -l', which uses it to print a suffix on each line, indicating whether the key is stored encrypted only (so it will need a passphrase on next use), or whether it's stored both encrypted _and_ unencrypted (so that 'pageant -R' will be able to return it to the former state).
2020-12-15 14:07:29 +00:00
kl1->keys[i].flags, &cbkey);
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
Pageant client: tolerate failure to list keys. This enables Pageant to act as a client for OpenSSH's agent, which nowadays refuses to respond to SSH1_AGENTC_REQUEST_RSA_IDENTITIES, or any other SSH1_AGENTC_* message. It now treats SSH_AGENT_FAILURE in response to either 'list identities' request the same as successfully receiving an empty list.
2020-03-03 21:44:19 +00:00
strbuf_free(cbkey.blob);
sfree(cbkey.comment);
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
ssh2_free_all_fingerprints(fingerprints);
Pageant client: tolerate failure to list keys. This enables Pageant to act as a client for OpenSSH's agent, which nowadays refuses to respond to SSH1_AGENTC_REQUEST_RSA_IDENTITIES, or any other SSH1_AGENTC_* message. It now treats SSH_AGENT_FAILURE in response to either 'list identities' request the same as successfully receiving an empty list.
2020-03-03 21:44:19 +00:00
}
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 client: tolerate failure to list keys. This enables Pageant to act as a client for OpenSSH's agent, which nowadays refuses to respond to SSH1_AGENTC_REQUEST_RSA_IDENTITIES, or any other SSH1_AGENTC_* message. It now treats SSH_AGENT_FAILURE in response to either 'list identities' request the same as successfully receiving an empty list.
2020-03-03 21:44:19 +00:00
if (kl2) {
for (size_t i = 0; i < kl2->nkeys; i++) {
Utility function strbuf_dup. If you already have a string (of potentially-binary data) in the form of a ptrlen reference to somewhere else, and you want to keep a copy somewhere, it's useful to copy it into a strbuf. But it takes a couple of lines of faff to do that, and it's nicer to wrap that up into a tiny helper function. This commit adds that helper function strbuf_dup, and its non-movable sibling strbuf_dup_nm for secret data. Also, gone through the existing code and found a bunch of cases where this makes things less verbose.
2022-04-19 09:53:44 +00:00
cbkey.blob = strbuf_dup(kl2->keys[i].blob);
Pageant client: tolerate failure to list keys. This enables Pageant to act as a client for OpenSSH's agent, which nowadays refuses to respond to SSH1_AGENTC_REQUEST_RSA_IDENTITIES, or any other SSH1_AGENTC_* message. It now treats SSH_AGENT_FAILURE in response to either 'list identities' request the same as successfully receiving an empty list.
2020-03-03 21:44:19 +00:00
cbkey.comment = mkstr(kl2->keys[i].comment);
cbkey.ssh_version = 2;
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
char **fingerprints =
ssh2_all_fingerprints_for_blob(kl2->keys[i].blob);
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
callback(callback_ctx, fingerprints, cbkey.comment,
pageant -l: indicate whether keys are encrypted. The callback function to pageant_enum_keys now takes a flags parameter, which receives the flags word from the extended key list request, if available. (If not, then the flags word is passed as zero.) The only callback that uses this parameter is the one for printing text output from 'pageant -l', which uses it to print a suffix on each line, indicating whether the key is stored encrypted only (so it will need a passphrase on next use), or whether it's stored both encrypted _and_ unencrypted (so that 'pageant -R' will be able to return it to the former state).
2020-12-15 14:07:29 +00:00
kl2->keys[i].flags, &cbkey);
Unix Pageant: support multiple fingerprint types. The callback-function API in pageant.h for key enumeration is modified so that we pass an array of all the available fingerprints for each key. In Unix Pageant, that's used by the -l option to print whichever fingerprint the user asked for. (Unfortunately, the option name -E is already taken, so for the moment I've called it --fptype. I may revisit that later.) Also, when matching a key by fingerprint, we're prepared to match against any fingerprint type we know, with disambiguating prefixes if necessary (e.g. you can match "md5:ab:12" or "sha256:Ab12". That has to be done a bit carefully, because we match MD5 hex fingerprints case-insensitively, but SHA256 fingerprints are case-sensitive.
2021-03-13 10:27:50 +00:00
ssh2_free_all_fingerprints(fingerprints);
Pageant client: tolerate failure to list keys. This enables Pageant to act as a client for OpenSSH's agent, which nowadays refuses to respond to SSH1_AGENTC_REQUEST_RSA_IDENTITIES, or any other SSH1_AGENTC_* message. It now treats SSH_AGENT_FAILURE in response to either 'list identities' request the same as successfully receiving an empty list.
2020-03-03 21:44:19 +00:00
sfree(cbkey.comment);
strbuf_free(cbkey.blob);
}
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
}
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
*retstr = NULL;
toret = PAGEANT_ACTION_OK;
out:
if (kl1)
keylist_free(kl1);
if (kl2)
keylist_free(kl2);
return toret;
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
int pageant_delete_key(struct pageant_pubkey *key, char **retstr)
{
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
PageantClientOp *pco = pageant_client_op_new();
Build outgoing SSH agent requests in a strbuf. This simplifies the client code both in ssh.c and in the client side of Pageant. I've cheated a tiny bit by preparing agent requests in a strbuf that has space reserved at the front for the packet frame, which makes life easier for the code that sends them off.
2018-05-24 12:18:13 +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
if (key->ssh_version == 1) {
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
put_byte(pco, SSH1_AGENTC_REMOVE_RSA_IDENTITY);
put_data(pco, key->blob->s, key->blob->len);
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 {
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
put_byte(pco, SSH2_AGENTC_REMOVE_IDENTITY);
put_string(pco, key->blob->s, key->blob->len);
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
}
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
unsigned reply = pageant_client_op_query(pco);
pageant_client_op_free(pco);
Build outgoing SSH agent requests in a strbuf. This simplifies the client code both in ssh.c and in the client side of Pageant. I've cheated a tiny bit by preparing agent requests in a strbuf that has space reserved at the front for the packet frame, which makes life easier for the code that sends them off.
2018-05-24 12:18:13 +00:00
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
if (reply != SSH_AGENT_SUCCESS) {
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
*retstr = dupstr("Agent failed to delete key");
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
return PAGEANT_ACTION_FAILURE;
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 {
*retstr = NULL;
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
return PAGEANT_ACTION_OK;
Unix Pageant: support -d, to delete a key from the agent. Unlike ssh-add, we can identify the key by its comment or by a prefix of its fingerprint as well as using a public key file on disk. The string given as an argument to -d is interpreted as whichever of those things matches; disambiguating prefixes are available if needed.
2015-05-12 12:27:33 +00:00
}
}
Unix Pageant: support -D, to delete all keys.
2015-05-12 13:55:44 +00:00
int pageant_delete_all_keys(char **retstr)
{
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
PageantClientOp *pco;
unsigned reply;
pco = pageant_client_op_new();
put_byte(pco, SSH2_AGENTC_REMOVE_ALL_IDENTITIES);
reply = pageant_client_op_query(pco);
pageant_client_op_free(pco);
if (reply != SSH_AGENT_SUCCESS) {
Unix Pageant: support -D, to delete all keys.
2015-05-12 13:55:44 +00:00
*retstr = dupstr("Agent failed to delete SSH-2 keys");
return PAGEANT_ACTION_FAILURE;
}
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
pco = pageant_client_op_new();
put_byte(pco, SSH1_AGENTC_REMOVE_ALL_RSA_IDENTITIES);
reply = pageant_client_op_query(pco);
pageant_client_op_free(pco);
if (reply != SSH_AGENT_SUCCESS) {
Unix Pageant: support -D, to delete all keys.
2015-05-12 13:55:44 +00:00
*retstr = dupstr("Agent failed to delete SSH-1 keys");
return PAGEANT_ACTION_FAILURE;
}
*retstr = NULL;
return PAGEANT_ACTION_OK;
}
Pageant client: functions to send reencryption requests. The reencrypt-all request is unusual in its ability to be _partially_ successful. To handle this I've introduced a new return status, PAGEANT_ACTION_WARNING. At the moment, users of this client code don't expect it to appear on any request, and I'll make them watch for it only in the case where I know a particular function can generate it.
2020-02-15 16:39:02 +00:00
int pageant_reencrypt_key(struct pageant_pubkey *key, char **retstr)
{
PageantClientOp *pco = pageant_client_op_new();
if (key->ssh_version == 1) {
*retstr = dupstr("Can't re-encrypt an SSH-1 key");
Fix a few memory leaks spotted by Coverity.
2021-04-09 16:55:31 +00:00
pageant_client_op_free(pco);
Pageant client: functions to send reencryption requests. The reencrypt-all request is unusual in its ability to be _partially_ successful. To handle this I've introduced a new return status, PAGEANT_ACTION_WARNING. At the moment, users of this client code don't expect it to appear on any request, and I'll make them watch for it only in the case where I know a particular function can generate it.
2020-02-15 16:39:02 +00:00
return PAGEANT_ACTION_FAILURE;
} else {
put_byte(pco, SSH2_AGENTC_EXTENSION);
put_stringpl(pco, extension_names[EXT_REENCRYPT]);
put_string(pco, key->blob->s, key->blob->len);
}
unsigned reply = pageant_client_op_query(pco);
pageant_client_op_free(pco);
if (reply != SSH_AGENT_SUCCESS) {
Pageant: Diagnose agent without protocol extensions. Gives more helpful messages if Unix pageant ends up being a client for, say, OpenSSH's ssh-agent, or indeed an older version of Pageant. (Also, tweak a couple of other messages that still assumed that pageant-as-client always talks to Pageant-as-agent.)
2021-04-05 14:20:25 +00:00
if (reply == SSH_AGENT_FAILURE) {
/* The agent didn't understand the protocol extension at all. */
*retstr = dupstr("Agent doesn't support encrypted keys");
} else {
*retstr = dupstr("Agent failed to re-encrypt key");
}
Pageant client: functions to send reencryption requests. The reencrypt-all request is unusual in its ability to be _partially_ successful. To handle this I've introduced a new return status, PAGEANT_ACTION_WARNING. At the moment, users of this client code don't expect it to appear on any request, and I'll make them watch for it only in the case where I know a particular function can generate it.
2020-02-15 16:39:02 +00:00
return PAGEANT_ACTION_FAILURE;
} else {
*retstr = NULL;
return PAGEANT_ACTION_OK;
}
}
int pageant_reencrypt_all_keys(char **retstr)
{
PageantClientOp *pco = pageant_client_op_new();
put_byte(pco, SSH2_AGENTC_EXTENSION);
put_stringpl(pco, extension_names[EXT_REENCRYPT_ALL]);
unsigned reply = pageant_client_op_query(pco);
uint32_t failures = get_uint32(pco);
pageant_client_op_free(pco);
if (reply != SSH_AGENT_SUCCESS) {
Pageant: Diagnose agent without protocol extensions. Gives more helpful messages if Unix pageant ends up being a client for, say, OpenSSH's ssh-agent, or indeed an older version of Pageant. (Also, tweak a couple of other messages that still assumed that pageant-as-client always talks to Pageant-as-agent.)
2021-04-05 14:20:25 +00:00
if (reply == SSH_AGENT_FAILURE) {
/* The agent didn't understand the protocol extension at all. */
*retstr = dupstr("Agent doesn't support encrypted keys");
} else {
*retstr = dupstr("Agent failed to re-encrypt any keys");
}
Pageant client: functions to send reencryption requests. The reencrypt-all request is unusual in its ability to be _partially_ successful. To handle this I've introduced a new return status, PAGEANT_ACTION_WARNING. At the moment, users of this client code don't expect it to appear on any request, and I'll make them watch for it only in the case where I know a particular function can generate it.
2020-02-15 16:39:02 +00:00
return PAGEANT_ACTION_FAILURE;
} else if (failures == 1) {
/* special case for English grammar */
*retstr = dupstr("1 key remains unencrypted");
return PAGEANT_ACTION_WARNING;
} else if (failures > 0) {
*retstr = dupprintf("%"PRIu32" keys remain unencrypted", failures);
return PAGEANT_ACTION_WARNING;
} else {
*retstr = NULL;
return PAGEANT_ACTION_OK;
}
}
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
int pageant_sign(struct pageant_pubkey *key, ptrlen message, strbuf *out,
uint32_t flags, char **retstr)
{
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
PageantClientOp *pco = pageant_client_op_new();
put_byte(pco, SSH2_AGENTC_SIGN_REQUEST);
put_string(pco, key->blob->s, key->blob->len);
put_stringpl(pco, message);
put_uint32(pco, flags);
unsigned reply = pageant_client_op_query(pco);
ptrlen signature = get_string(pco);
if (reply == SSH2_AGENT_SIGN_RESPONSE && !get_err(pco)) {
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
*retstr = NULL;
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
put_datapl(out, signature);
pageant_client_op_free(pco);
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
return PAGEANT_ACTION_OK;
} else {
*retstr = dupstr("Agent failed to create signature");
Rework the Pageant client code to use BinarySource. There was a lot of ugly, repetitive, error-prone code that decoded agent responses in raw data buffers. Now my internal client query function is returning something that works as a BinarySource, so we can decode agent responses using the marshal.h system like any other SSH-formatted message in this code base. While I'm at it, I've centralised more of the parsing of key lists (saving repetition in pageant_add_key and pageant_enum_keys), including merging most of the logic between SSH-1 and SSH-2. The old functions pageant_get_keylist1 and pageant_get_keylist2 aren't exposed in pageant.h any more, because they no longer exist in that form, and also because nothing was using them anyway. (Windows Pageant was using the separate pageant_nth_ssh2_key() functions that talk directly to the core, and Unix Pageant was using the more cooked client function pageant_enum_keys.)
2020-02-15 07:30:19 +00:00
pageant_client_op_free(pco);
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
return PAGEANT_ACTION_FAILURE;
}
}
Rename 'ret' variables passed from allocation to return. I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no longer fond of the variable name 'ret', because it's used in two quite different contexts: it's the return value from a subroutine you just called (e.g. 'int ret = read(fd, buf, len);' and then check for error or EOF), or it's the value you're preparing to return from the _containing_ routine (maybe by assigning it a default value and then conditionally modifying it, or by starting at NULL and reallocating, or setting it just before using the 'goto out' cleanup idiom). In the past I've occasionally made mistakes by forgetting which meaning the variable had, or accidentally conflating both uses. If all else fails, I now prefer 'retd' (short for 'returned') in the former situation, and 'toret' (obviously, the value 'to return') in the latter case. But even better is to pick a name that actually says something more specific about what the thing actually is. One particular bad habit throughout this codebase is to have a set of functions that deal with some object type (say 'Foo'), all *but one* of which take a 'Foo *foo' parameter, but the foo_new() function starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the canonical name for the ambient Foo is 'foo', so should foo_new()! So here's a no-brainer start on cutting down on the uses of 'ret': I looked for all the cases where it was being assigned the result of an allocation, and renamed the variable to be a description of the thing being allocated. In the case of a new() function belonging to a family, I picked the same name as the rest of the functions in its own family, for consistency. In other cases I picked something sensible. One case where it _does_ make sense not to use your usual name for the variable type is when you're cloning an existing object. In that case, _neither_ of the Foo objects involved should be called 'foo', because it's ambiguous! They should be named so you can see which is which. In the two cases I found here, I've called them 'orig' and 'copy'. As in the previous refactoring, many thanks to clang-rename for the help.
2022-09-13 13:53:36 +00:00
struct pageant_pubkey *pageant_pubkey_copy(struct pageant_pubkey *orig)
{
struct pageant_pubkey *copy = snew(struct pageant_pubkey);
copy->blob = strbuf_new();
put_data(copy->blob, orig->blob->s, orig->blob->len);
copy->comment = orig->comment ? dupstr(orig->comment) : NULL;
copy->ssh_version = orig->ssh_version;
return copy;
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
}
void pageant_pubkey_free(struct pageant_pubkey *key)
{
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
sfree(key->comment);
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->blob);
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
sfree(key);
}
Reference in New Issue Copy Permalink