github
/
putty
зеркало из https://github.com/github/putty.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
putty/ssh.h

1550 строки
63 KiB
C
Исходник Обычный вид История

Move prototypes for base64_decode_atom(), base64_lines(), and base64_encode() from import.c to ssh.h, so that the implementation can see them. This necessitates ssh.h's including <stdio.h>. Also remove a spare prototype for base64_encode_atom() from import.c. [originally from svn r2481]
2003-01-06 02:28:02 +03:00
#include <stdio.h>
John Sullivan's patches plus more fixes: - Stop using the identifier `environ' as some platforms make it a macro - Fix silly error box at end of connection in FWHACK mode - Fix GPF on maximise-then-restore - Use SetCapture to allow drag-selecting outside the window - Correctly update window title when iconic and in win_name_always mode [originally from svn r12]
1999-01-08 16:10:19 +03:00
#include <string.h>
Make memory management uniform: _everything_ now goes through the smalloc() macros and thence to the safemalloc() functions in misc.c. This should allow me to plug in a debugging allocator and track memory leaks and segfaults and things. [originally from svn r818]
2000-12-12 13:33:13 +03:00
#include "puttymem.h"
Revamp of the local X11 connection code. We now parse X display strings more rigorously, and then we look up the local X authority data in .Xauthority _ourself_ rather than delegating to an external xauth program. This is (negligibly) more efficient on Unix, assuming I haven't got it wrong in some subtle way, but its major benefit is that we can now support X authority lookups on Windows as well provided the user points us at an appropriate X authority file in the standard format. A new Windows-specific config option has been added for this purpose. [originally from svn r8305]
2008-11-17 21:38:09 +03:00
#include "tree234.h"
SSH port forwarding! How cool is that? Only currently works on SSH1; SSH2 should be doable but it's late and I have other things to do tonight. The Cool Guy award for this one goes to Nicolas Barry, for doing most of the work and actually understanding the code he was adding to. [originally from svn r1176]
2001-08-09 00:44:35 +04:00
#include "network.h"
Created new data types `Filename' and `FontSpec', intended to be opaque to all platform-independent modules and only handled within per-platform code. `Filename' is there because the Mac has a magic way to store filenames (though currently this checkin doesn't support it!); `FontSpec' is there so that all the auxiliary stuff such as font height and charset and so on which is needed under Windows but not Unix can be kept where it belongs, and so that I can have a hope in hell of dealing with a font chooser in the forthcoming cross-platform config box code, and best of all it gets the horrid font height wart out of settings.c and into the Windows code where it should be. The Mac part of this checkin is a bunch of random guesses which will probably not quite compile, but which look roughly right to me. Sorry if I screwed it up, Ben :-) [originally from svn r2765]
2003-02-01 15:54:40 +03:00
#include "misc.h"
Make memory management uniform: _everything_ now goes through the smalloc() macros and thence to the safemalloc() functions in misc.c. This should allow me to plug in a debugging allocator and track memory leaks and segfaults and things. [originally from svn r818]
2000-12-12 13:33:13 +03:00
Cygwin build fixes: update the dependencies, add -DNO_SECURITY to the Cygwin CFLAGS, and declare `struct ssh_channel' in ssh.h to prevent gcc warning about scope-confined-to-parameter-list. [originally from svn r1268]
2001-09-15 18:58:26 +04:00
struct ssh_channel;
Move some ssh.c declarations into header files. ssh.c has been an unmanageably huge monolith of a source file for too long, and it's finally time I started breaking it up into smaller pieces. The first step is to move some declarations - basic types like packets and packet queues, standard constants, enums, and the coroutine system - into headers where other files can see them.
2018-06-09 11:07:18 +03:00
/*
* Buffer management constants. There are several of these for
* various different purposes:
*
* - SSH1_BUFFER_LIMIT is the amount of backlog that must build up
* on a local data stream before we throttle the whole SSH
* connection (in SSH-1 only). Throttling the whole connection is
* pretty drastic so we set this high in the hope it won't
* happen very often.
*
* - SSH_MAX_BACKLOG is the amount of backlog that must build up
* on the SSH connection itself before we defensively throttle
* _all_ local data streams. This is pretty drastic too (though
* thankfully unlikely in SSH-2 since the window mechanism should
* ensure that the server never has any need to throttle its end
* of the connection), so we set this high as well.
*
* - OUR_V2_WINSIZE is the default window size we present on SSH-2
* channels.
*
* - OUR_V2_BIGWIN is the window size we advertise for the only
* channel in a simple connection. It must be <= INT_MAX.
*
* - OUR_V2_MAXPKT is the official "maximum packet size" we send
* to the remote side. This actually has nothing to do with the
* size of the _packet_, but is instead a limit on the amount
* of data we're willing to receive in a single SSH2 channel
* data message.
*
* - OUR_V2_PACKETLIMIT is actually the maximum size of SSH
* _packet_ we're prepared to cope with. It must be a multiple
* of the cipher block size, and must be at least 35000.
*/
#define SSH1_BUFFER_LIMIT 32768
#define SSH_MAX_BACKLOG 32768
#define OUR_V2_WINSIZE 16384
#define OUR_V2_BIGWIN 0x7fffffff
#define OUR_V2_MAXPKT 0x4000UL
#define OUR_V2_PACKETLIMIT 0x9000UL
typedef struct PacketQueueNode PacketQueueNode;
struct PacketQueueNode {
PacketQueueNode *next, *prev;
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 22:23:19 +03:00
bool on_free_queue; /* is this packet scheduled for freeing? */
Move some ssh.c declarations into header files. ssh.c has been an unmanageably huge monolith of a source file for too long, and it's finally time I started breaking it up into smaller pieces. The first step is to move some declarations - basic types like packets and packet queues, standard constants, enums, and the coroutine system - into headers where other files can see them.
2018-06-09 11:07:18 +03:00
};
typedef struct PktIn {
int type;
unsigned long sequence; /* SSH-2 incoming sequence number */
PacketQueueNode qnode; /* for linking this packet on to a queue */
BinarySource_IMPLEMENTATION;
} PktIn;
typedef struct PktOut {
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 23:07:30 +03:00
size_t prefix; /* bytes up to and including type field */
size_t length; /* total bytes, including prefix */
Move some ssh.c declarations into header files. ssh.c has been an unmanageably huge monolith of a source file for too long, and it's finally time I started breaking it up into smaller pieces. The first step is to move some declarations - basic types like packets and packet queues, standard constants, enums, and the coroutine system - into headers where other files can see them.
2018-06-09 11:07:18 +03:00
int type;
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 23:07:30 +03:00
size_t minlen; /* SSH-2: ensure wire length is at least this */
Move some ssh.c declarations into header files. ssh.c has been an unmanageably huge monolith of a source file for too long, and it's finally time I started breaking it up into smaller pieces. The first step is to move some declarations - basic types like packets and packet queues, standard constants, enums, and the coroutine system - into headers where other files can see them.
2018-06-09 11:07:18 +03:00
unsigned char *data; /* allocated storage */
New array-growing macros: sgrowarray and sgrowarrayn. The idea of these is that they centralise the common idiom along the lines of if (logical_array_len >= physical_array_size) { physical_array_size = logical_array_len * 5 / 4 + 256; array = sresize(array, physical_array_size, ElementType); } which happens at a zillion call sites throughout this code base, with different random choices of the geometric factor and additive constant, sometimes forgetting them completely, and generally doing a lot of repeated work. The new macro sgrowarray(array,size,n) has the semantics: here are the array pointer and its physical size for you to modify, now please ensure that the nth element exists, so I can write into it. And sgrowarrayn(array,size,n,m) is the same except that it ensures that the array has size at least n+m (so sgrowarray is just the special case where m=1). Now that this is a single centralised implementation that will be used everywhere, I've also gone to more effort in the implementation, with careful overflow checks that would have been painful to put at all the previous call sites. This commit also switches over every use of sresize(), apart from a few where I really didn't think it would gain anything. A consequence of that is that a lot of array-size variables have to have their types changed to size_t, because the macros require that (they address-take the size to pass to the underlying function).
2019-02-28 23:07:30 +03:00
size_t maxlen; /* amount of storage allocated for `data' */
Move some ssh.c declarations into header files. ssh.c has been an unmanageably huge monolith of a source file for too long, and it's finally time I started breaking it up into smaller pieces. The first step is to move some declarations - basic types like packets and packet queues, standard constants, enums, and the coroutine system - into headers where other files can see them.
2018-06-09 11:07:18 +03:00
/* Extra metadata used in SSH packet logging mode, allowing us to
* log in the packet header line that the packet came from a
* connection-sharing downstream and what if anything unusual was
* done to it. The additional_log_text field is expected to be a
* static string - it will not be freed. */
unsigned downstream_id;
const char *additional_log_text;
Extend PacketQueue to take PktOut as well. Some upcoming restructuring I've got planned will need to pass output packets back and forth on queues, as well as input ones. So here's a change that arranges that we can have a PktInQueue and a PktOutQueue, sharing most of their implementation via a PacketQueueBase structure which links together the PacketQueueNode fields in the two packet structures. There's a tricksy bit of macro manoeuvring to get all of this type-checked, so that I can't accidentally link a PktOut on to a PktInQueue or vice versa. It works by having the main queue functions wrapped by macros; when receiving a packet structure on input, they type-check it against the queue structure and then automatically look up its qnode field to pass to the underlying PacketQueueBase function; on output, they translate a returned PacketQueueNode back to its containing packet type by calling a 'get' function pointer.
2018-09-19 23:56:11 +03:00
PacketQueueNode qnode; /* for linking this packet on to a queue */
Move some ssh.c declarations into header files. ssh.c has been an unmanageably huge monolith of a source file for too long, and it's finally time I started breaking it up into smaller pieces. The first step is to move some declarations - basic types like packets and packet queues, standard constants, enums, and the coroutine system - into headers where other files can see them.
2018-06-09 11:07:18 +03:00
BinarySink_IMPLEMENTATION;
} PktOut;
Extend PacketQueue to take PktOut as well. Some upcoming restructuring I've got planned will need to pass output packets back and forth on queues, as well as input ones. So here's a change that arranges that we can have a PktInQueue and a PktOutQueue, sharing most of their implementation via a PacketQueueBase structure which links together the PacketQueueNode fields in the two packet structures. There's a tricksy bit of macro manoeuvring to get all of this type-checked, so that I can't accidentally link a PktOut on to a PktInQueue or vice versa. It works by having the main queue functions wrapped by macros; when receiving a packet structure on input, they type-check it against the queue structure and then automatically look up its qnode field to pass to the underlying PacketQueueBase function; on output, they translate a returned PacketQueueNode back to its containing packet type by calling a 'get' function pointer.
2018-09-19 23:56:11 +03:00
typedef struct PacketQueueBase {
Move some ssh.c declarations into header files. ssh.c has been an unmanageably huge monolith of a source file for too long, and it's finally time I started breaking it up into smaller pieces. The first step is to move some declarations - basic types like packets and packet queues, standard constants, enums, and the coroutine system - into headers where other files can see them.
2018-06-09 11:07:18 +03:00
PacketQueueNode end;
Put an optional IdempotentCallback in packet queues. This means that someone putting things on a packet queue doesn't need to separately hold a pointer to someone who needs notifying about it, or remember to call the notification function every time they push things on the queue. It's all taken care of automatically, without having to put extra stuff at the call sites. The precise semantics are that the callback will be scheduled whenever _new_ packets appear on the queue, but not when packets are removed. (Because the expectation is that the callback is notifying whoever is consuming the queue.)
2018-09-21 15:16:38 +03:00
struct IdempotentCallback *ic;
Extend PacketQueue to take PktOut as well. Some upcoming restructuring I've got planned will need to pass output packets back and forth on queues, as well as input ones. So here's a change that arranges that we can have a PktInQueue and a PktOutQueue, sharing most of their implementation via a PacketQueueBase structure which links together the PacketQueueNode fields in the two packet structures. There's a tricksy bit of macro manoeuvring to get all of this type-checked, so that I can't accidentally link a PktOut on to a PktInQueue or vice versa. It works by having the main queue functions wrapped by macros; when receiving a packet structure on input, they type-check it against the queue structure and then automatically look up its qnode field to pass to the underlying PacketQueueBase function; on output, they translate a returned PacketQueueNode back to its containing packet type by calling a 'get' function pointer.
2018-09-19 23:56:11 +03:00
} PacketQueueBase;
typedef struct PktInQueue {
PacketQueueBase pqb;
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 22:23:19 +03:00
PktIn *(*after)(PacketQueueBase *, PacketQueueNode *prev, bool pop);
Extend PacketQueue to take PktOut as well. Some upcoming restructuring I've got planned will need to pass output packets back and forth on queues, as well as input ones. So here's a change that arranges that we can have a PktInQueue and a PktOutQueue, sharing most of their implementation via a PacketQueueBase structure which links together the PacketQueueNode fields in the two packet structures. There's a tricksy bit of macro manoeuvring to get all of this type-checked, so that I can't accidentally link a PktOut on to a PktInQueue or vice versa. It works by having the main queue functions wrapped by macros; when receiving a packet structure on input, they type-check it against the queue structure and then automatically look up its qnode field to pass to the underlying PacketQueueBase function; on output, they translate a returned PacketQueueNode back to its containing packet type by calling a 'get' function pointer.
2018-09-19 23:56:11 +03:00
} PktInQueue;
typedef struct PktOutQueue {
PacketQueueBase pqb;
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 22:23:19 +03:00
PktOut *(*after)(PacketQueueBase *, PacketQueueNode *prev, bool pop);
Extend PacketQueue to take PktOut as well. Some upcoming restructuring I've got planned will need to pass output packets back and forth on queues, as well as input ones. So here's a change that arranges that we can have a PktInQueue and a PktOutQueue, sharing most of their implementation via a PacketQueueBase structure which links together the PacketQueueNode fields in the two packet structures. There's a tricksy bit of macro manoeuvring to get all of this type-checked, so that I can't accidentally link a PktOut on to a PktInQueue or vice versa. It works by having the main queue functions wrapped by macros; when receiving a packet structure on input, they type-check it against the queue structure and then automatically look up its qnode field to pass to the underlying PacketQueueBase function; on output, they translate a returned PacketQueueNode back to its containing packet type by calling a 'get' function pointer.
2018-09-19 23:56:11 +03:00
} PktOutQueue;
void pq_base_push(PacketQueueBase *pqb, PacketQueueNode *node);
void pq_base_push_front(PacketQueueBase *pqb, PacketQueueNode *node);
Make pq_empty_on_to_front_of more general. It's really just a concatenator for a pair of linked lists, but unhelpfully restricted in which of the lists it replaces with the output. Better to have a three-argument function that puts the output wherever you like, whether it overlaps either or neither one of the inputs.
2018-09-19 22:30:40 +03:00
void pq_base_concatenate(PacketQueueBase *dest,
PacketQueueBase *q1, PacketQueueBase *q2);
Extend PacketQueue to take PktOut as well. Some upcoming restructuring I've got planned will need to pass output packets back and forth on queues, as well as input ones. So here's a change that arranges that we can have a PktInQueue and a PktOutQueue, sharing most of their implementation via a PacketQueueBase structure which links together the PacketQueueNode fields in the two packet structures. There's a tricksy bit of macro manoeuvring to get all of this type-checked, so that I can't accidentally link a PktOut on to a PktInQueue or vice versa. It works by having the main queue functions wrapped by macros; when receiving a packet structure on input, they type-check it against the queue structure and then automatically look up its qnode field to pass to the underlying PacketQueueBase function; on output, they translate a returned PacketQueueNode back to its containing packet type by calling a 'get' function pointer.
2018-09-19 23:56:11 +03:00
void pq_in_init(PktInQueue *pq);
void pq_out_init(PktOutQueue *pq);
void pq_in_clear(PktInQueue *pq);
void pq_out_clear(PktOutQueue *pq);
Utility routines for iterating over a packet queue. I haven't needed these until now, but I'm about to need to inspect the entire contents of a packet queue before deciding whether to process the first item on it. I've changed the single 'vtable method' in packet queues from get(), which returned the head of the queue and optionally popped it, to after() which does the same bug returns the item after a specified tree node. So if you pass the special end node to after(), then it behaves like get(), but now you can also use it to retrieve the successor of a packet. (Orthogonality says that you can also _pop_ the successor of a packet by calling after() with prev != pq.end and pop == TRUE. I don't have a use for that one yet.)
2018-10-06 20:42:08 +03:00
#define pq_push(pq, pkt) \
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 22:50:29 +03:00
TYPECHECK((pq)->after(&(pq)->pqb, NULL, false) == pkt, \
Extend PacketQueue to take PktOut as well. Some upcoming restructuring I've got planned will need to pass output packets back and forth on queues, as well as input ones. So here's a change that arranges that we can have a PktInQueue and a PktOutQueue, sharing most of their implementation via a PacketQueueBase structure which links together the PacketQueueNode fields in the two packet structures. There's a tricksy bit of macro manoeuvring to get all of this type-checked, so that I can't accidentally link a PktOut on to a PktInQueue or vice versa. It works by having the main queue functions wrapped by macros; when receiving a packet structure on input, they type-check it against the queue structure and then automatically look up its qnode field to pass to the underlying PacketQueueBase function; on output, they translate a returned PacketQueueNode back to its containing packet type by calling a 'get' function pointer.
2018-09-19 23:56:11 +03:00
pq_base_push(&(pq)->pqb, &(pkt)->qnode))
#define pq_push_front(pq, pkt) \
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 22:50:29 +03:00
TYPECHECK((pq)->after(&(pq)->pqb, NULL, false) == pkt, \
Extend PacketQueue to take PktOut as well. Some upcoming restructuring I've got planned will need to pass output packets back and forth on queues, as well as input ones. So here's a change that arranges that we can have a PktInQueue and a PktOutQueue, sharing most of their implementation via a PacketQueueBase structure which links together the PacketQueueNode fields in the two packet structures. There's a tricksy bit of macro manoeuvring to get all of this type-checked, so that I can't accidentally link a PktOut on to a PktInQueue or vice versa. It works by having the main queue functions wrapped by macros; when receiving a packet structure on input, they type-check it against the queue structure and then automatically look up its qnode field to pass to the underlying PacketQueueBase function; on output, they translate a returned PacketQueueNode back to its containing packet type by calling a 'get' function pointer.
2018-09-19 23:56:11 +03:00
pq_base_push_front(&(pq)->pqb, &(pkt)->qnode))
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 22:50:29 +03:00
#define pq_peek(pq) ((pq)->after(&(pq)->pqb, &(pq)->pqb.end, false))
#define pq_pop(pq) ((pq)->after(&(pq)->pqb, &(pq)->pqb.end, true))
Utility routines for iterating over a packet queue. I haven't needed these until now, but I'm about to need to inspect the entire contents of a packet queue before deciding whether to process the first item on it. I've changed the single 'vtable method' in packet queues from get(), which returned the head of the queue and optionally popped it, to after() which does the same bug returns the item after a specified tree node. So if you pass the special end node to after(), then it behaves like get(), but now you can also use it to retrieve the successor of a packet. (Orthogonality says that you can also _pop_ the successor of a packet by calling after() with prev != pq.end and pop == TRUE. I don't have a use for that one yet.)
2018-10-06 20:42:08 +03:00
#define pq_concatenate(dst, q1, q2) \
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 22:50:29 +03:00
TYPECHECK((q1)->after(&(q1)->pqb, NULL, false) == \
(dst)->after(&(dst)->pqb, NULL, false) && \
(q2)->after(&(q2)->pqb, NULL, false) == \
(dst)->after(&(dst)->pqb, NULL, false), \
Make pq_empty_on_to_front_of more general. It's really just a concatenator for a pair of linked lists, but unhelpfully restricted in which of the lists it replaces with the output. Better to have a three-argument function that puts the output wherever you like, whether it overlaps either or neither one of the inputs.
2018-09-19 22:30:40 +03:00
pq_base_concatenate(&(dst)->pqb, &(q1)->pqb, &(q2)->pqb))
Move some ssh.c declarations into header files. ssh.c has been an unmanageably huge monolith of a source file for too long, and it's finally time I started breaking it up into smaller pieces. The first step is to move some declarations - basic types like packets and packet queues, standard constants, enums, and the coroutine system - into headers where other files can see them.
2018-06-09 11:07:18 +03:00
Utility routines for iterating over a packet queue. I haven't needed these until now, but I'm about to need to inspect the entire contents of a packet queue before deciding whether to process the first item on it. I've changed the single 'vtable method' in packet queues from get(), which returned the head of the queue and optionally popped it, to after() which does the same bug returns the item after a specified tree node. So if you pass the special end node to after(), then it behaves like get(), but now you can also use it to retrieve the successor of a packet. (Orthogonality says that you can also _pop_ the successor of a packet by calling after() with prev != pq.end and pop == TRUE. I don't have a use for that one yet.)
2018-10-06 20:42:08 +03:00
#define pq_first(pq) pq_peek(pq)
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 22:50:29 +03:00
#define pq_next(pq, pkt) ((pq)->after(&(pq)->pqb, &(pkt)->qnode, false))
Utility routines for iterating over a packet queue. I haven't needed these until now, but I'm about to need to inspect the entire contents of a packet queue before deciding whether to process the first item on it. I've changed the single 'vtable method' in packet queues from get(), which returned the head of the queue and optionally popped it, to after() which does the same bug returns the item after a specified tree node. So if you pass the special end node to after(), then it behaves like get(), but now you can also use it to retrieve the successor of a packet. (Orthogonality says that you can also _pop_ the successor of a packet by calling after() with prev != pq.end and pop == TRUE. I don't have a use for that one yet.)
2018-10-06 20:42:08 +03:00
Move some ssh.c declarations into header files. ssh.c has been an unmanageably huge monolith of a source file for too long, and it's finally time I started breaking it up into smaller pieces. The first step is to move some declarations - basic types like packets and packet queues, standard constants, enums, and the coroutine system - into headers where other files can see them.
2018-06-09 11:07:18 +03:00
/*
* Packet type contexts, so that ssh2_pkt_type can correctly decode
* the ambiguous type numbers back into the correct type strings.
*/
typedef enum {
SSH2_PKTCTX_NOKEX,
SSH2_PKTCTX_DHGROUP,
SSH2_PKTCTX_DHGEX,
SSH2_PKTCTX_ECDHKEX,
SSH2_PKTCTX_GSSKEX,
SSH2_PKTCTX_RSAKEX
} Pkt_KCtx;
typedef enum {
SSH2_PKTCTX_NOAUTH,
SSH2_PKTCTX_PUBLICKEY,
SSH2_PKTCTX_PASSWORD,
SSH2_PKTCTX_GSSAPI,
SSH2_PKTCTX_KBDINTER
} Pkt_ACtx;
Move binary packet protocols and censoring out of ssh.c. sshbpp.h now defines a classoid that encapsulates both directions of an SSH binary packet protocol - that is, a system for reading a bufchain of incoming data and turning it into a stream of PktIn, and another system for taking a PktOut and turning it into data on an outgoing bufchain. The state structure in each of those files contains everything that used to be in the 'rdpkt2_state' structure and its friends, and also quite a lot of bits and pieces like cipher and MAC states that used to live in the main Ssh structure. One minor effect of this layer separation is that I've had to extend the packet dispatch table by one, because the BPP layer can no longer directly trigger sending of SSH_MSG_UNIMPLEMENTED for a message too short to have a type byte. Instead, I extend the PktIn type field to use an out-of-range value to encode that, and the easiest way to make that trigger an UNIMPLEMENTED message is to have the dispatch table contain an entry for it. (That's a system that may come in useful again - I was also wondering about inventing a fake type code to indicate network EOF, so that that could be propagated through the layers and be handled by whichever one currently knew best how to respond.) I've also moved the packet-censoring code into its own pair of files, partly because I was going to want to do that anyway sooner or later, and mostly because it's called from the BPP code, and the SSH-2 version in particular has to be called from both the main SSH-2 BPP and the bare unencrypted protocol used for connection sharing. While I was at it, I took the opportunity to merge the outgoing and incoming censor functions, so that the parts that were common between them (e.g. CHANNEL_DATA messages look the same in both directions) didn't need to be repeated.
2018-06-09 11:09:10 +03:00
typedef struct PacketLogSettings {
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 22:23:19 +03:00
bool omit_passwords, omit_data;
Move binary packet protocols and censoring out of ssh.c. sshbpp.h now defines a classoid that encapsulates both directions of an SSH binary packet protocol - that is, a system for reading a bufchain of incoming data and turning it into a stream of PktIn, and another system for taking a PktOut and turning it into data on an outgoing bufchain. The state structure in each of those files contains everything that used to be in the 'rdpkt2_state' structure and its friends, and also quite a lot of bits and pieces like cipher and MAC states that used to live in the main Ssh structure. One minor effect of this layer separation is that I've had to extend the packet dispatch table by one, because the BPP layer can no longer directly trigger sending of SSH_MSG_UNIMPLEMENTED for a message too short to have a type byte. Instead, I extend the PktIn type field to use an out-of-range value to encode that, and the easiest way to make that trigger an UNIMPLEMENTED message is to have the dispatch table contain an entry for it. (That's a system that may come in useful again - I was also wondering about inventing a fake type code to indicate network EOF, so that that could be propagated through the layers and be handled by whichever one currently knew best how to respond.) I've also moved the packet-censoring code into its own pair of files, partly because I was going to want to do that anyway sooner or later, and mostly because it's called from the BPP code, and the SSH-2 version in particular has to be called from both the main SSH-2 BPP and the bare unencrypted protocol used for connection sharing. While I was at it, I took the opportunity to merge the outgoing and incoming censor functions, so that the parts that were common between them (e.g. CHANNEL_DATA messages look the same in both directions) didn't need to be repeated.
2018-06-09 11:09:10 +03:00
Pkt_KCtx kctx;
Pkt_ACtx actx;
} PacketLogSettings;
#define MAX_BLANKS 4 /* no packet needs more censored sections than this */
int ssh1_censor_packet(
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 22:23:19 +03:00
const PacketLogSettings *pls, int type, bool sender_is_client,
Move binary packet protocols and censoring out of ssh.c. sshbpp.h now defines a classoid that encapsulates both directions of an SSH binary packet protocol - that is, a system for reading a bufchain of incoming data and turning it into a stream of PktIn, and another system for taking a PktOut and turning it into data on an outgoing bufchain. The state structure in each of those files contains everything that used to be in the 'rdpkt2_state' structure and its friends, and also quite a lot of bits and pieces like cipher and MAC states that used to live in the main Ssh structure. One minor effect of this layer separation is that I've had to extend the packet dispatch table by one, because the BPP layer can no longer directly trigger sending of SSH_MSG_UNIMPLEMENTED for a message too short to have a type byte. Instead, I extend the PktIn type field to use an out-of-range value to encode that, and the easiest way to make that trigger an UNIMPLEMENTED message is to have the dispatch table contain an entry for it. (That's a system that may come in useful again - I was also wondering about inventing a fake type code to indicate network EOF, so that that could be propagated through the layers and be handled by whichever one currently knew best how to respond.) I've also moved the packet-censoring code into its own pair of files, partly because I was going to want to do that anyway sooner or later, and mostly because it's called from the BPP code, and the SSH-2 version in particular has to be called from both the main SSH-2 BPP and the bare unencrypted protocol used for connection sharing. While I was at it, I took the opportunity to merge the outgoing and incoming censor functions, so that the parts that were common between them (e.g. CHANNEL_DATA messages look the same in both directions) didn't need to be repeated.
2018-06-09 11:09:10 +03:00
ptrlen pkt, logblank_t *blanks);
int ssh2_censor_packet(
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 22:23:19 +03:00
const PacketLogSettings *pls, int type, bool sender_is_client,
Move binary packet protocols and censoring out of ssh.c. sshbpp.h now defines a classoid that encapsulates both directions of an SSH binary packet protocol - that is, a system for reading a bufchain of incoming data and turning it into a stream of PktIn, and another system for taking a PktOut and turning it into data on an outgoing bufchain. The state structure in each of those files contains everything that used to be in the 'rdpkt2_state' structure and its friends, and also quite a lot of bits and pieces like cipher and MAC states that used to live in the main Ssh structure. One minor effect of this layer separation is that I've had to extend the packet dispatch table by one, because the BPP layer can no longer directly trigger sending of SSH_MSG_UNIMPLEMENTED for a message too short to have a type byte. Instead, I extend the PktIn type field to use an out-of-range value to encode that, and the easiest way to make that trigger an UNIMPLEMENTED message is to have the dispatch table contain an entry for it. (That's a system that may come in useful again - I was also wondering about inventing a fake type code to indicate network EOF, so that that could be propagated through the layers and be handled by whichever one currently knew best how to respond.) I've also moved the packet-censoring code into its own pair of files, partly because I was going to want to do that anyway sooner or later, and mostly because it's called from the BPP code, and the SSH-2 version in particular has to be called from both the main SSH-2 BPP and the bare unencrypted protocol used for connection sharing. While I was at it, I took the opportunity to merge the outgoing and incoming censor functions, so that the parts that were common between them (e.g. CHANNEL_DATA messages look the same in both directions) didn't need to be repeated.
2018-06-09 11:09:10 +03:00
ptrlen pkt, logblank_t *blanks);
PktOut *ssh_new_packet(void);
Move some ssh.c declarations into header files. ssh.c has been an unmanageably huge monolith of a source file for too long, and it's finally time I started breaking it up into smaller pieces. The first step is to move some declarations - basic types like packets and packet queues, standard constants, enums, and the coroutine system - into headers where other files can see them.
2018-06-09 11:07:18 +03:00
void ssh_free_pktout(PktOut *pkt);
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 21:26:18 +03:00
Socket *ssh_connection_sharing_init(
const char *host, int port, Conf *conf, LogContext *logctx,
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 21:10:23 +03:00
Plug *sshplug, ssh_sharing_state **state);
Defer passing a ConnectionLayer to sshshare.c. This paves the way for me to reorganise ssh.c in a way that will mean I don't have a ConnectionLayer available yet at the time I have to create the connshare. The constructor function now takes a mere Frontend, for generating setup-time Event Log messages, and there's a separate ssh_connshare_provide_connlayer() function I can call later once I have the ConnectionLayer to provide. NFC for the moment: the new provide_connlayer function is called immediately after ssh_connection_sharing_init.
2018-09-21 19:00:36 +03:00
void ssh_connshare_provide_connlayer(ssh_sharing_state *sharestate,
ConnectionLayer *cl);
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 22:23:19 +03:00
bool ssh_share_test_for_upstream(const char *host, int port, Conf *conf);
Expose structure tags for the connection-sharing data types. This was a particularly confusing piece of type-danger, because three different types were passed outside sshshare.c as 'void *' and only human vigilance prevented one coming back as the wrong one. Now they all keep their opaque structure tags when they move through other parts of the code.
2018-09-13 11:09:10 +03:00
void share_got_pkt_from_server(ssh_sharing_connstate *ctx, int type,
Make share_got_pkt_from_server take a const pointer. It was horrible - even if harmless in practice - that it wrote the NATed channel id over its input buffer, and I think it's worth the extra memory management to avoid doing that.
2018-06-06 09:19:57 +03:00
const void *pkt, int pktlen);
Expose structure tags for the connection-sharing data types. This was a particularly confusing piece of type-danger, because three different types were passed outside sshshare.c as 'void *' and only human vigilance prevented one coming back as the wrong one. Now they all keep their opaque structure tags when they move through other parts of the code.
2018-09-13 11:09:10 +03:00
void share_activate(ssh_sharing_state *sharestate,
const char *server_verstring);
void sharestate_free(ssh_sharing_state *state);
int share_ndownstreams(ssh_sharing_state *state);
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 18:05:41 +04: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 21:10:23 +03:00
void ssh_connshare_log(Ssh *ssh, int event, const char *logtext,
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 18:05:41 +04:00
const char *ds_err, const char *us_err);
Expose structure tags for the connection-sharing data types. This was a particularly confusing piece of type-danger, because three different types were passed outside sshshare.c as 'void *' and only human vigilance prevented one coming back as the wrong one. Now they all keep their opaque structure tags when they move through other parts of the code.
2018-09-13 11:09:10 +03:00
void share_setup_x11_channel(ssh_sharing_connstate *cs, share_channel *chan,
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 18:05:41 +04:00
unsigned upstream_id, unsigned server_id,
unsigned server_currwin, unsigned server_maxpkt,
unsigned client_adjusted_window,
const char *peer_addr, int peer_port, int endian,
int protomajor, int protominor,
const void *initial_data, int initial_len);
Extensive changes that _should_ fix the socket buffering problems, by ceasing to listen on input channels if the corresponding output channel isn't accepting data. Has had basic check-I-didn't-actually- break-anything-too-badly testing, but hasn't been genuinely tested in stress conditions (because concocting stress conditions is non- trivial). [originally from svn r1198]
2001-08-25 21:09:23 +04:00
Move all extern declarations into header files. This is another cleanup I felt a need for while I was doing boolification. If you define a function or variable in one .c file and declare it extern in another, then nothing will check you haven't got the types of the two declarations mismatched - so when you're _changing_ the type, it's a pain to make sure you've caught all the copies of it. It's better to put all those extern declarations in header files, so that the declaration in the header is also in scope for the definition. Then the compiler will complain if they don't match, which is what I want.
2018-11-03 13:06:33 +03:00
/* Per-application overrides for what roles we can take in connection
* sharing, regardless of user configuration (e.g. pscp will never be
* an upstream) */
extern const bool share_can_be_downstream;
extern const bool share_can_be_upstream;
Move mainchan into its own file, like agentf. This gets another big pile of logic out of ssh2connection and puts it somewhere more central. Now the only thing left in ssh2connection is the formatting and parsing of the various channel requests; the logic deciding which ones to issue and what to do about them is devolved to the Channel implementation, as it properly should be.
2018-09-30 09:16:38 +03:00
struct X11Display;
struct X11FakeAuth;
Move most of ssh.c out into separate source files. I've tried to separate out as many individually coherent changes from this work as I could into their own commits, but here's where I run out and have to commit the rest of this major refactoring as a big-bang change. Most of ssh.c is now no longer in ssh.c: all five of the main coroutines that handle layers of the SSH-1 and SSH-2 protocols now each have their own source file to live in, and a lot of the supporting functions have moved into the appropriate one of those too. The new abstraction is a vtable called 'PacketProtocolLayer', which has an input and output packet queue. Each layer's main coroutine is invoked from the method ssh_ppl_process_queue(), which is usually (though not exclusively) triggered automatically when things are pushed on the input queue. In SSH-2, the base layer is the transport protocol, and it contains a pair of subsidiary queues by which it passes some of its packets to the higher SSH-2 layers - first userauth and then connection, which are peers at the same level, with the former abdicating in favour of the latter at the appropriate moment. SSH-1 is simpler: the whole login phase of the protocol (crypto setup and authentication) is all in one module, and since SSH-1 has no repeat key exchange, that setup layer abdicates in favour of the connection phase when it's done. ssh.c itself is now about a tenth of its old size (which all by itself is cause for celebration!). Its main job is to set up all the layers, hook them up to each other and to the BPP, and to funnel data back and forth between that collection of modules and external things such as the network and the terminal. Once it's set up a collection of packet protocol layers, it communicates with them partly by calling methods of the base layer (and if that's ssh2transport then it will delegate some functionality to the corresponding methods of its higher layer), and partly by talking directly to the connection layer no matter where it is in the stack by means of the separate ConnectionLayer vtable which I introduced in commit 8001dd4cb, and to which I've now added quite a few extra methods replacing services that used to be internal function calls within ssh.c. (One effect of this is that the SSH-1 and SSH-2 channel storage is now no longer shared - there are distinct struct types ssh1_channel and ssh2_channel. That means a bit more code duplication, but on the plus side, a lot fewer confusing conditionals in the middle of half-shared functions, and less risk of a piece of SSH-1 escaping into SSH-2 or vice versa, which I remember has happened at least once in the past.) The bulk of this commit introduces the five new source files, their common header sshppl.h and some shared supporting routines in sshcommon.c, and rewrites nearly all of ssh.c itself. But it also includes a couple of other changes that I couldn't separate easily enough: Firstly, there's a new handling for socket EOF, in which ssh.c sets an 'input_eof' flag in the BPP, and that responds by checking a flag that tells it whether to report the EOF as an error or not. (This is the main reason for those new BPP_READ / BPP_WAITFOR macros - they can check the EOF flag every time the coroutine is resumed.) Secondly, the error reporting itself is changed around again. I'd expected to put some data fields in the public PacketProtocolLayer structure that it could set to report errors in the same way as the BPPs have been doing, but in the end, I decided propagating all those data fields around was a pain and that even the BPPs shouldn't have been doing it that way. So I've reverted to a system where everything calls back to functions in ssh.c itself to report any connection- ending condition. But there's a new family of those functions, categorising the possible such conditions by semantics, and each one has a different set of detailed effects (e.g. how rudely to close the network connection, what exit status should be passed back to the whole application, whether to send a disconnect message and/or display a GUI error box). I don't expect this to be immediately perfect: of course, the code has been through a big upheaval, new bugs are expected, and I haven't been able to do a full job of testing (e.g. I haven't tested every auth or kex method). But I've checked that it _basically_ works - both SSH protocols, all the different kinds of forwarding channel, more than one auth method, Windows and Linux, connection sharing - and I think it's now at the point where the easiest way to find further bugs is to let it out into the wild and see what users can spot.
2018-09-24 20:28:16 +03:00
/* Structure definition centralised here because the SSH-1 and SSH-2
* connection layers both use it. But the client module (portfwd.c)
* should not try to look inside here. */
struct ssh_rportfwd {
unsigned sport, dport;
char *shost, *dhost;
int addressfamily;
char *log_description; /* name of remote listening port, for logging */
ssh_sharing_connstate *share_ctx;
PortFwdRecord *pfr;
};
void free_rportfwd(struct ssh_rportfwd *rpf);
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
struct ConnectionLayerVtable {
/* Allocate and free remote-to-local port forwardings, called by
* PortFwdManager or by connection sharing */
struct ssh_rportfwd *(*rportfwd_alloc)(
ConnectionLayer *cl,
const char *shost, int sport, const char *dhost, int dport,
int addressfamily, const char *log_description, PortFwdRecord *pfr,
ssh_sharing_connstate *share_ctx);
void (*rportfwd_remove)(ConnectionLayer *cl, struct ssh_rportfwd *rpf);
/* Open a local-to-remote port forwarding channel, called by
* PortFwdManager */
SshChannel *(*lportfwd_open)(
ConnectionLayer *cl, const char *hostname, int port,
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 22:06:42 +03:00
const char *description, const SocketPeerInfo *peerinfo,
Channel *chan);
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
Move mainchan into its own file, like agentf. This gets another big pile of logic out of ssh2connection and puts it somewhere more central. Now the only thing left in ssh2connection is the formatting and parsing of the various channel requests; the logic deciding which ones to issue and what to do about them is devolved to the Channel implementation, as it properly should be.
2018-09-30 09:16:38 +03:00
/* Initiate opening of a 'session'-type channel */
SshChannel *(*session_open)(ConnectionLayer *cl, Channel *chan);
Add an actual SSH server program. This server is NOT SECURE! If anyone is reading this commit message, DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to speak the server end of everything PuTTY speaks on the client side, so that I can test that I haven't broken PuTTY when I reorganise its code, even things like RSA key exchange or chained auth methods which it's hard to find a server that speaks at all. (For this reason, it's declared with [UT] in the Recipe file, so that it falls into the same category as programs like testbn, which won't be installed by 'make install'.) Working title is 'Uppity', partly for 'Universal PuTTY Protocol Interaction Test Yoke', but mostly because it looks quite like the word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a very rarely used term meaning something not altogether unlike 'test harness', which is a bit of a stretch, but it'll do.) It doesn't actually _support_ everything I want yet. At the moment, it's a proof of concept only. But it has most of the machinery present, and the parts it's missing - such as chained auth methods - should be easy enough to add because I've built in the required flexibility, in the form of an AuthPolicy object which can request them if it wants to. However, the current AuthPolicy object is entirely trivial, and will let in any user with the password "weasel". (Another way in which this is not a production-ready server is that it also has no interaction with the OS's authentication system. In particular, it will not only let in any user with the same password, but it won't even change uid - it will open shells and forwardings under whatever user id you started it up as.) Currently, the program can only speak the SSH protocol on its standard I/O channels (using the new FdSocket facility), so if you want it to listen on a network port, you'll have to run it from some kind of separate listening program similar to inetd. For my own tests, I'm not even doing that: I'm just having PuTTY spawn it as a local proxy process, which also conveniently eliminates the risk of anyone hostile connecting to it. The bulk of the actual code reorganisation is already done by previous commits, so this change is _mostly_ just dropping in a new set of server-specific source files alongside the client-specific ones I created recently. The remaining changes in the shared SSH code are numerous, but all minor: - a few extra parameters to BPP and PPL constructors (e.g. 'are you in server mode?'), and pass both sets of SSH-1 protocol flags from the login to the connection layer - in server mode, unconditionally send our version string _before_ waiting for the remote one - a new hook in the SSH-1 BPP to handle enabling compression in server mode, where the message exchange works the other way round - new code in the SSH-2 BPP to do _deferred_ compression the other way round (the non-deferred version is still nicely symmetric) - in the SSH-2 transport layer, some adjustments to do key derivation either way round (swapping round the identifying letters in the various hash preimages, and making sure to list the KEXINITs in the right order) - also in the SSH-2 transport layer, an if statement that controls whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or vice versa - new ConnectionLayer methods for opening outgoing channels for X and agent forwardings - new functions in portfwd.c to establish listening sockets suitable for remote-to-local port forwarding (i.e. not under the direction of a Conf the way it's done on the client side).
2018-10-21 00:09:54 +03:00
/* Open outgoing channels for X and agent forwarding. (Used in the
* SSH server.) */
SshChannel *(*serverside_x11_open)(ConnectionLayer *cl, Channel *chan,
const SocketPeerInfo *pi);
SshChannel *(*serverside_agent_open)(ConnectionLayer *cl, Channel *chan);
Move mainchan into its own file, like agentf. This gets another big pile of logic out of ssh2connection and puts it somewhere more central. Now the only thing left in ssh2connection is the formatting and parsing of the various channel requests; the logic deciding which ones to issue and what to do about them is devolved to the Channel implementation, as it properly should be.
2018-09-30 09:16:38 +03:00
/* Add an X11 display for ordinary X forwarding */
struct X11FakeAuth *(*add_x11_display)(
ConnectionLayer *cl, int authtype, struct X11Display *x11disp);
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
/* Add and remove X11 displays for connection sharing downstreams */
struct X11FakeAuth *(*add_sharing_x11_display)(
ConnectionLayer *cl, int authtype, ssh_sharing_connstate *share_cs,
share_channel *share_chan);
void (*remove_sharing_x11_display)(
ConnectionLayer *cl, struct X11FakeAuth *auth);
/* Pass through an outgoing SSH packet from a downstream */
void (*send_packet_from_downstream)(
ConnectionLayer *cl, unsigned id, int type,
const void *pkt, int pktlen, const char *additional_log_text);
/* Allocate/free an upstream channel number associated with a
* sharing downstream */
unsigned (*alloc_sharing_channel)(ConnectionLayer *cl,
ssh_sharing_connstate *connstate);
void (*delete_sharing_channel)(ConnectionLayer *cl, unsigned localid);
/* Indicate that a downstream has sent a global request with the
* want-reply flag, so that when a reply arrives it will be passed
* back to that downstrean */
void (*sharing_queue_global_request)(
ConnectionLayer *cl, ssh_sharing_connstate *connstate);
sshshare: notify cl when last downstream goes away. The check_termination function in ssh2connection is supposed to be called whenever it's possible that we've run out of (a) channels, and (b) sharing downstreams. I've been calling it on every channel close, but apparently completely forgot to add a callback from sshshare.c that also arranges to call it when we run out of downstreams.
2018-09-28 22:52:36 +03:00
/* Indicate that the last downstream has disconnected */
void (*sharing_no_more_downstreams)(ConnectionLayer *cl);
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
/* Query whether the connection layer is doing agent forwarding */
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 22:23:19 +03:00
bool (*agent_forwarding_permitted)(ConnectionLayer *cl);
Move most of ssh.c out into separate source files. I've tried to separate out as many individually coherent changes from this work as I could into their own commits, but here's where I run out and have to commit the rest of this major refactoring as a big-bang change. Most of ssh.c is now no longer in ssh.c: all five of the main coroutines that handle layers of the SSH-1 and SSH-2 protocols now each have their own source file to live in, and a lot of the supporting functions have moved into the appropriate one of those too. The new abstraction is a vtable called 'PacketProtocolLayer', which has an input and output packet queue. Each layer's main coroutine is invoked from the method ssh_ppl_process_queue(), which is usually (though not exclusively) triggered automatically when things are pushed on the input queue. In SSH-2, the base layer is the transport protocol, and it contains a pair of subsidiary queues by which it passes some of its packets to the higher SSH-2 layers - first userauth and then connection, which are peers at the same level, with the former abdicating in favour of the latter at the appropriate moment. SSH-1 is simpler: the whole login phase of the protocol (crypto setup and authentication) is all in one module, and since SSH-1 has no repeat key exchange, that setup layer abdicates in favour of the connection phase when it's done. ssh.c itself is now about a tenth of its old size (which all by itself is cause for celebration!). Its main job is to set up all the layers, hook them up to each other and to the BPP, and to funnel data back and forth between that collection of modules and external things such as the network and the terminal. Once it's set up a collection of packet protocol layers, it communicates with them partly by calling methods of the base layer (and if that's ssh2transport then it will delegate some functionality to the corresponding methods of its higher layer), and partly by talking directly to the connection layer no matter where it is in the stack by means of the separate ConnectionLayer vtable which I introduced in commit 8001dd4cb, and to which I've now added quite a few extra methods replacing services that used to be internal function calls within ssh.c. (One effect of this is that the SSH-1 and SSH-2 channel storage is now no longer shared - there are distinct struct types ssh1_channel and ssh2_channel. That means a bit more code duplication, but on the plus side, a lot fewer confusing conditionals in the middle of half-shared functions, and less risk of a piece of SSH-1 escaping into SSH-2 or vice versa, which I remember has happened at least once in the past.) The bulk of this commit introduces the five new source files, their common header sshppl.h and some shared supporting routines in sshcommon.c, and rewrites nearly all of ssh.c itself. But it also includes a couple of other changes that I couldn't separate easily enough: Firstly, there's a new handling for socket EOF, in which ssh.c sets an 'input_eof' flag in the BPP, and that responds by checking a flag that tells it whether to report the EOF as an error or not. (This is the main reason for those new BPP_READ / BPP_WAITFOR macros - they can check the EOF flag every time the coroutine is resumed.) Secondly, the error reporting itself is changed around again. I'd expected to put some data fields in the public PacketProtocolLayer structure that it could set to report errors in the same way as the BPPs have been doing, but in the end, I decided propagating all those data fields around was a pain and that even the BPPs shouldn't have been doing it that way. So I've reverted to a system where everything calls back to functions in ssh.c itself to report any connection- ending condition. But there's a new family of those functions, categorising the possible such conditions by semantics, and each one has a different set of detailed effects (e.g. how rudely to close the network connection, what exit status should be passed back to the whole application, whether to send a disconnect message and/or display a GUI error box). I don't expect this to be immediately perfect: of course, the code has been through a big upheaval, new bugs are expected, and I haven't been able to do a full job of testing (e.g. I haven't tested every auth or kex method). But I've checked that it _basically_ works - both SSH protocols, all the different kinds of forwarding channel, more than one auth method, Windows and Linux, connection sharing - and I think it's now at the point where the easiest way to find further bugs is to let it out into the wild and see what users can spot.
2018-09-24 20:28:16 +03:00
/* Set the size of the main terminal window (if any) */
void (*terminal_size)(ConnectionLayer *cl, int width, int height);
/* Indicate that the backlog on standard output has cleared */
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 23:42:44 +03:00
void (*stdout_unthrottle)(ConnectionLayer *cl, size_t bufsize);
Move most of ssh.c out into separate source files. I've tried to separate out as many individually coherent changes from this work as I could into their own commits, but here's where I run out and have to commit the rest of this major refactoring as a big-bang change. Most of ssh.c is now no longer in ssh.c: all five of the main coroutines that handle layers of the SSH-1 and SSH-2 protocols now each have their own source file to live in, and a lot of the supporting functions have moved into the appropriate one of those too. The new abstraction is a vtable called 'PacketProtocolLayer', which has an input and output packet queue. Each layer's main coroutine is invoked from the method ssh_ppl_process_queue(), which is usually (though not exclusively) triggered automatically when things are pushed on the input queue. In SSH-2, the base layer is the transport protocol, and it contains a pair of subsidiary queues by which it passes some of its packets to the higher SSH-2 layers - first userauth and then connection, which are peers at the same level, with the former abdicating in favour of the latter at the appropriate moment. SSH-1 is simpler: the whole login phase of the protocol (crypto setup and authentication) is all in one module, and since SSH-1 has no repeat key exchange, that setup layer abdicates in favour of the connection phase when it's done. ssh.c itself is now about a tenth of its old size (which all by itself is cause for celebration!). Its main job is to set up all the layers, hook them up to each other and to the BPP, and to funnel data back and forth between that collection of modules and external things such as the network and the terminal. Once it's set up a collection of packet protocol layers, it communicates with them partly by calling methods of the base layer (and if that's ssh2transport then it will delegate some functionality to the corresponding methods of its higher layer), and partly by talking directly to the connection layer no matter where it is in the stack by means of the separate ConnectionLayer vtable which I introduced in commit 8001dd4cb, and to which I've now added quite a few extra methods replacing services that used to be internal function calls within ssh.c. (One effect of this is that the SSH-1 and SSH-2 channel storage is now no longer shared - there are distinct struct types ssh1_channel and ssh2_channel. That means a bit more code duplication, but on the plus side, a lot fewer confusing conditionals in the middle of half-shared functions, and less risk of a piece of SSH-1 escaping into SSH-2 or vice versa, which I remember has happened at least once in the past.) The bulk of this commit introduces the five new source files, their common header sshppl.h and some shared supporting routines in sshcommon.c, and rewrites nearly all of ssh.c itself. But it also includes a couple of other changes that I couldn't separate easily enough: Firstly, there's a new handling for socket EOF, in which ssh.c sets an 'input_eof' flag in the BPP, and that responds by checking a flag that tells it whether to report the EOF as an error or not. (This is the main reason for those new BPP_READ / BPP_WAITFOR macros - they can check the EOF flag every time the coroutine is resumed.) Secondly, the error reporting itself is changed around again. I'd expected to put some data fields in the public PacketProtocolLayer structure that it could set to report errors in the same way as the BPPs have been doing, but in the end, I decided propagating all those data fields around was a pain and that even the BPPs shouldn't have been doing it that way. So I've reverted to a system where everything calls back to functions in ssh.c itself to report any connection- ending condition. But there's a new family of those functions, categorising the possible such conditions by semantics, and each one has a different set of detailed effects (e.g. how rudely to close the network connection, what exit status should be passed back to the whole application, whether to send a disconnect message and/or display a GUI error box). I don't expect this to be immediately perfect: of course, the code has been through a big upheaval, new bugs are expected, and I haven't been able to do a full job of testing (e.g. I haven't tested every auth or kex method). But I've checked that it _basically_ works - both SSH protocols, all the different kinds of forwarding channel, more than one auth method, Windows and Linux, connection sharing - and I think it's now at the point where the easiest way to find further bugs is to let it out into the wild and see what users can spot.
2018-09-24 20:28:16 +03:00
/* Query the size of the backlog on standard _input_ */
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 23:42:44 +03:00
size_t (*stdin_backlog)(ConnectionLayer *cl);
Move most of ssh.c out into separate source files. I've tried to separate out as many individually coherent changes from this work as I could into their own commits, but here's where I run out and have to commit the rest of this major refactoring as a big-bang change. Most of ssh.c is now no longer in ssh.c: all five of the main coroutines that handle layers of the SSH-1 and SSH-2 protocols now each have their own source file to live in, and a lot of the supporting functions have moved into the appropriate one of those too. The new abstraction is a vtable called 'PacketProtocolLayer', which has an input and output packet queue. Each layer's main coroutine is invoked from the method ssh_ppl_process_queue(), which is usually (though not exclusively) triggered automatically when things are pushed on the input queue. In SSH-2, the base layer is the transport protocol, and it contains a pair of subsidiary queues by which it passes some of its packets to the higher SSH-2 layers - first userauth and then connection, which are peers at the same level, with the former abdicating in favour of the latter at the appropriate moment. SSH-1 is simpler: the whole login phase of the protocol (crypto setup and authentication) is all in one module, and since SSH-1 has no repeat key exchange, that setup layer abdicates in favour of the connection phase when it's done. ssh.c itself is now about a tenth of its old size (which all by itself is cause for celebration!). Its main job is to set up all the layers, hook them up to each other and to the BPP, and to funnel data back and forth between that collection of modules and external things such as the network and the terminal. Once it's set up a collection of packet protocol layers, it communicates with them partly by calling methods of the base layer (and if that's ssh2transport then it will delegate some functionality to the corresponding methods of its higher layer), and partly by talking directly to the connection layer no matter where it is in the stack by means of the separate ConnectionLayer vtable which I introduced in commit 8001dd4cb, and to which I've now added quite a few extra methods replacing services that used to be internal function calls within ssh.c. (One effect of this is that the SSH-1 and SSH-2 channel storage is now no longer shared - there are distinct struct types ssh1_channel and ssh2_channel. That means a bit more code duplication, but on the plus side, a lot fewer confusing conditionals in the middle of half-shared functions, and less risk of a piece of SSH-1 escaping into SSH-2 or vice versa, which I remember has happened at least once in the past.) The bulk of this commit introduces the five new source files, their common header sshppl.h and some shared supporting routines in sshcommon.c, and rewrites nearly all of ssh.c itself. But it also includes a couple of other changes that I couldn't separate easily enough: Firstly, there's a new handling for socket EOF, in which ssh.c sets an 'input_eof' flag in the BPP, and that responds by checking a flag that tells it whether to report the EOF as an error or not. (This is the main reason for those new BPP_READ / BPP_WAITFOR macros - they can check the EOF flag every time the coroutine is resumed.) Secondly, the error reporting itself is changed around again. I'd expected to put some data fields in the public PacketProtocolLayer structure that it could set to report errors in the same way as the BPPs have been doing, but in the end, I decided propagating all those data fields around was a pain and that even the BPPs shouldn't have been doing it that way. So I've reverted to a system where everything calls back to functions in ssh.c itself to report any connection- ending condition. But there's a new family of those functions, categorising the possible such conditions by semantics, and each one has a different set of detailed effects (e.g. how rudely to close the network connection, what exit status should be passed back to the whole application, whether to send a disconnect message and/or display a GUI error box). I don't expect this to be immediately perfect: of course, the code has been through a big upheaval, new bugs are expected, and I haven't been able to do a full job of testing (e.g. I haven't tested every auth or kex method). But I've checked that it _basically_ works - both SSH protocols, all the different kinds of forwarding channel, more than one auth method, Windows and Linux, connection sharing - and I think it's now at the point where the easiest way to find further bugs is to let it out into the wild and see what users can spot.
2018-09-24 20:28:16 +03:00
/* Tell the connection layer that the SSH connection itself has
* backed up, so it should tell all currently open channels to
* cease reading from their local input sources if they can. (Or
* tell it that that state of affairs has gone away again.) */
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 22:23:19 +03:00
void (*throttle_all_channels)(ConnectionLayer *cl, bool throttled);
Move most of ssh.c out into separate source files. I've tried to separate out as many individually coherent changes from this work as I could into their own commits, but here's where I run out and have to commit the rest of this major refactoring as a big-bang change. Most of ssh.c is now no longer in ssh.c: all five of the main coroutines that handle layers of the SSH-1 and SSH-2 protocols now each have their own source file to live in, and a lot of the supporting functions have moved into the appropriate one of those too. The new abstraction is a vtable called 'PacketProtocolLayer', which has an input and output packet queue. Each layer's main coroutine is invoked from the method ssh_ppl_process_queue(), which is usually (though not exclusively) triggered automatically when things are pushed on the input queue. In SSH-2, the base layer is the transport protocol, and it contains a pair of subsidiary queues by which it passes some of its packets to the higher SSH-2 layers - first userauth and then connection, which are peers at the same level, with the former abdicating in favour of the latter at the appropriate moment. SSH-1 is simpler: the whole login phase of the protocol (crypto setup and authentication) is all in one module, and since SSH-1 has no repeat key exchange, that setup layer abdicates in favour of the connection phase when it's done. ssh.c itself is now about a tenth of its old size (which all by itself is cause for celebration!). Its main job is to set up all the layers, hook them up to each other and to the BPP, and to funnel data back and forth between that collection of modules and external things such as the network and the terminal. Once it's set up a collection of packet protocol layers, it communicates with them partly by calling methods of the base layer (and if that's ssh2transport then it will delegate some functionality to the corresponding methods of its higher layer), and partly by talking directly to the connection layer no matter where it is in the stack by means of the separate ConnectionLayer vtable which I introduced in commit 8001dd4cb, and to which I've now added quite a few extra methods replacing services that used to be internal function calls within ssh.c. (One effect of this is that the SSH-1 and SSH-2 channel storage is now no longer shared - there are distinct struct types ssh1_channel and ssh2_channel. That means a bit more code duplication, but on the plus side, a lot fewer confusing conditionals in the middle of half-shared functions, and less risk of a piece of SSH-1 escaping into SSH-2 or vice versa, which I remember has happened at least once in the past.) The bulk of this commit introduces the five new source files, their common header sshppl.h and some shared supporting routines in sshcommon.c, and rewrites nearly all of ssh.c itself. But it also includes a couple of other changes that I couldn't separate easily enough: Firstly, there's a new handling for socket EOF, in which ssh.c sets an 'input_eof' flag in the BPP, and that responds by checking a flag that tells it whether to report the EOF as an error or not. (This is the main reason for those new BPP_READ / BPP_WAITFOR macros - they can check the EOF flag every time the coroutine is resumed.) Secondly, the error reporting itself is changed around again. I'd expected to put some data fields in the public PacketProtocolLayer structure that it could set to report errors in the same way as the BPPs have been doing, but in the end, I decided propagating all those data fields around was a pain and that even the BPPs shouldn't have been doing it that way. So I've reverted to a system where everything calls back to functions in ssh.c itself to report any connection- ending condition. But there's a new family of those functions, categorising the possible such conditions by semantics, and each one has a different set of detailed effects (e.g. how rudely to close the network connection, what exit status should be passed back to the whole application, whether to send a disconnect message and/or display a GUI error box). I don't expect this to be immediately perfect: of course, the code has been through a big upheaval, new bugs are expected, and I haven't been able to do a full job of testing (e.g. I haven't tested every auth or kex method). But I've checked that it _basically_ works - both SSH protocols, all the different kinds of forwarding channel, more than one auth method, Windows and Linux, connection sharing - and I think it's now at the point where the easiest way to find further bugs is to let it out into the wild and see what users can spot.
2018-09-24 20:28:16 +03:00
/* Ask the connection layer about its current preference for
* line-discipline options. */
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 22:23:19 +03:00
bool (*ldisc_option)(ConnectionLayer *cl, int option);
Move mainchan into its own file, like agentf. This gets another big pile of logic out of ssh2connection and puts it somewhere more central. Now the only thing left in ssh2connection is the formatting and parsing of the various channel requests; the logic deciding which ones to issue and what to do about them is devolved to the Channel implementation, as it properly should be.
2018-09-30 09:16:38 +03:00
/* Communicate _to_ the connection layer (from the main session
* channel) what its preference for line-discipline options is. */
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 22:23:19 +03:00
void (*set_ldisc_option)(ConnectionLayer *cl, int option, bool value);
Move mainchan into its own file, like agentf. This gets another big pile of logic out of ssh2connection and puts it somewhere more central. Now the only thing left in ssh2connection is the formatting and parsing of the various channel requests; the logic deciding which ones to issue and what to do about them is devolved to the Channel implementation, as it properly should be.
2018-09-30 09:16:38 +03:00
/* Communicate to the connection layer whether X and agent
* forwarding were successfully enabled (for purposes of
* knowing whether to accept subsequent channel-opens). */
void (*enable_x_fwd)(ConnectionLayer *cl);
void (*enable_agent_fwd)(ConnectionLayer *cl);
/* Communicate to the connection layer whether the main session
* channel currently wants user input. */
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 22:23:19 +03:00
void (*set_wants_user_input)(ConnectionLayer *cl, bool wanted);
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
};
struct ConnectionLayer {
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 21:26:18 +03:00
LogContext *logctx;
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
const struct ConnectionLayerVtable *vt;
};
Replace method-dispatch #defines with inline functions. This replaces all the macros like ssh_key_sign() and win_draw_text() which take an object containing a vtable pointer and do the dereferencing to find the actual concrete method to call. Now they're all inline functions, which means more sensible type-checking and more comprehensible error reports when the types go wrong, and also means that there's no risk of double-evaluating the object argument.
2019-02-27 22:44:15 +03:00
static inline struct ssh_rportfwd *ssh_rportfwd_alloc(
ConnectionLayer *cl, const char *sh, int sp, const char *dh, int dp,
int af, const char *log, PortFwdRecord *pfr, ssh_sharing_connstate *cs)
{ return cl->vt->rportfwd_alloc(cl, sh, sp, dh, dp, af, log, pfr, cs); }
static inline void ssh_rportfwd_remove(
ConnectionLayer *cl, struct ssh_rportfwd *rpf)
{ cl->vt->rportfwd_remove(cl, rpf); }
static inline SshChannel *ssh_lportfwd_open(
ConnectionLayer *cl, const char *host, int port,
const char *desc, const SocketPeerInfo *pi, Channel *chan)
{ return cl->vt->lportfwd_open(cl, host, port, desc, pi, chan); }
static inline SshChannel *ssh_session_open(ConnectionLayer *cl, Channel *chan)
{ return cl->vt->session_open(cl, chan); }
static inline SshChannel *ssh_serverside_x11_open(
ConnectionLayer *cl, Channel *chan, const SocketPeerInfo *pi)
{ return cl->vt->serverside_x11_open(cl, chan, pi); }
static inline SshChannel *ssh_serverside_agent_open(
ConnectionLayer *cl, Channel *chan)
{ return cl->vt->serverside_agent_open(cl, chan); }
static inline struct X11FakeAuth *ssh_add_x11_display(
ConnectionLayer *cl, int authtype, struct X11Display *x11disp)
{ return cl->vt->add_x11_display(cl, authtype, x11disp); }
static inline struct X11FakeAuth *ssh_add_sharing_x11_display(
ConnectionLayer *cl, int authtype, ssh_sharing_connstate *share_cs,
share_channel *share_chan)
{ return cl->vt->add_sharing_x11_display(cl, authtype, share_cs, share_chan); }
static inline void ssh_remove_sharing_x11_display(
ConnectionLayer *cl, struct X11FakeAuth *auth)
{ cl->vt->remove_sharing_x11_display(cl, auth); }
static inline void ssh_send_packet_from_downstream(
ConnectionLayer *cl, unsigned id, int type,
const void *pkt, int len, const char *log)
{ cl->vt->send_packet_from_downstream(cl, id, type, pkt, len, log); }
static inline unsigned ssh_alloc_sharing_channel(
ConnectionLayer *cl, ssh_sharing_connstate *connstate)
{ return cl->vt->alloc_sharing_channel(cl, connstate); }
static inline void ssh_delete_sharing_channel(
ConnectionLayer *cl, unsigned localid)
{ cl->vt->delete_sharing_channel(cl, localid); }
static inline void ssh_sharing_queue_global_request(
ConnectionLayer *cl, ssh_sharing_connstate *connstate)
{ cl->vt->sharing_queue_global_request(cl, connstate); }
static inline void ssh_sharing_no_more_downstreams(ConnectionLayer *cl)
{ cl->vt->sharing_no_more_downstreams(cl); }
static inline bool ssh_agent_forwarding_permitted(ConnectionLayer *cl)
{ return cl->vt->agent_forwarding_permitted(cl); }
static inline void ssh_terminal_size(ConnectionLayer *cl, int w, int h)
{ cl->vt->terminal_size(cl, w, h); }
static inline void ssh_stdout_unthrottle(ConnectionLayer *cl, size_t bufsize)
{ cl->vt->stdout_unthrottle(cl, bufsize); }
static inline size_t ssh_stdin_backlog(ConnectionLayer *cl)
{ return cl->vt->stdin_backlog(cl); }
static inline void ssh_throttle_all_channels(ConnectionLayer *cl, bool thr)
{ cl->vt->throttle_all_channels(cl, thr); }
static inline bool ssh_ldisc_option(ConnectionLayer *cl, int option)
{ return cl->vt->ldisc_option(cl, option); }
static inline void ssh_set_ldisc_option(ConnectionLayer *cl, int opt, bool val)
{ cl->vt->set_ldisc_option(cl, opt, val); }
static inline void ssh_enable_x_fwd(ConnectionLayer *cl)
{ cl->vt->enable_x_fwd(cl); }
static inline void ssh_enable_agent_fwd(ConnectionLayer *cl)
{ cl->vt->enable_agent_fwd(cl); }
static inline void ssh_set_wants_user_input(ConnectionLayer *cl, bool wanted)
{ cl->vt->set_wants_user_input(cl, wanted); }
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
/* Exports from portfwd.c */
New abstraction 'ConnectionLayer'. This is a vtable that wraps up all the functionality required from the SSH connection layer by associated modules like port forwarding and connection sharing. This extra layer of indirection adds nothing useful right now, but when I later separate the SSH-1 and SSH-2 connection layer implementations, it will be convenient for each one to be able to implement this vtable in terms of its own internal data structures. To simplify this vtable, I've moved a lot of the logging duties relating to connection sharing out of ssh.c into sshshare.c: now it handles nearly all the logging itself relating to setting up connection sharing in the first place and downstreams connecting and disconnecting. The only exception is the 'Reusing a shared connection' announcement in the console window, which is now done in ssh.c by detecting downstream status immediately after setup.
2018-09-17 14:14:00 +03:00
PortFwdManager *portfwdmgr_new(ConnectionLayer *cl);
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
void portfwdmgr_free(PortFwdManager *mgr);
void portfwdmgr_config(PortFwdManager *mgr, Conf *conf);
void portfwdmgr_close(PortFwdManager *mgr, PortFwdRecord *pfr);
void portfwdmgr_close_all(PortFwdManager *mgr);
char *portfwdmgr_connect(PortFwdManager *mgr, Channel **chan_ret,
char *hostname, int port, SshChannel *c,
int addressfamily);
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 22:23:19 +03:00
bool portfwdmgr_listen(PortFwdManager *mgr, const char *host, int port,
const char *keyhost, int keyport, Conf *conf);
bool portfwdmgr_unlisten(PortFwdManager *mgr, const char *host, int port);
Add an actual SSH server program. This server is NOT SECURE! If anyone is reading this commit message, DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to speak the server end of everything PuTTY speaks on the client side, so that I can test that I haven't broken PuTTY when I reorganise its code, even things like RSA key exchange or chained auth methods which it's hard to find a server that speaks at all. (For this reason, it's declared with [UT] in the Recipe file, so that it falls into the same category as programs like testbn, which won't be installed by 'make install'.) Working title is 'Uppity', partly for 'Universal PuTTY Protocol Interaction Test Yoke', but mostly because it looks quite like the word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a very rarely used term meaning something not altogether unlike 'test harness', which is a bit of a stretch, but it'll do.) It doesn't actually _support_ everything I want yet. At the moment, it's a proof of concept only. But it has most of the machinery present, and the parts it's missing - such as chained auth methods - should be easy enough to add because I've built in the required flexibility, in the form of an AuthPolicy object which can request them if it wants to. However, the current AuthPolicy object is entirely trivial, and will let in any user with the password "weasel". (Another way in which this is not a production-ready server is that it also has no interaction with the OS's authentication system. In particular, it will not only let in any user with the same password, but it won't even change uid - it will open shells and forwardings under whatever user id you started it up as.) Currently, the program can only speak the SSH protocol on its standard I/O channels (using the new FdSocket facility), so if you want it to listen on a network port, you'll have to run it from some kind of separate listening program similar to inetd. For my own tests, I'm not even doing that: I'm just having PuTTY spawn it as a local proxy process, which also conveniently eliminates the risk of anyone hostile connecting to it. The bulk of the actual code reorganisation is already done by previous commits, so this change is _mostly_ just dropping in a new set of server-specific source files alongside the client-specific ones I created recently. The remaining changes in the shared SSH code are numerous, but all minor: - a few extra parameters to BPP and PPL constructors (e.g. 'are you in server mode?'), and pass both sets of SSH-1 protocol flags from the login to the connection layer - in server mode, unconditionally send our version string _before_ waiting for the remote one - a new hook in the SSH-1 BPP to handle enabling compression in server mode, where the message exchange works the other way round - new code in the SSH-2 BPP to do _deferred_ compression the other way round (the non-deferred version is still nicely symmetric) - in the SSH-2 transport layer, some adjustments to do key derivation either way round (swapping round the identifying letters in the various hash preimages, and making sure to list the KEXINITs in the right order) - also in the SSH-2 transport layer, an if statement that controls whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or vice versa - new ConnectionLayer methods for opening outgoing channels for X and agent forwardings - new functions in portfwd.c to establish listening sockets suitable for remote-to-local port forwarding (i.e. not under the direction of a Conf the way it's done on the client side).
2018-10-21 00:09:54 +03:00
Channel *portfwd_raw_new(ConnectionLayer *cl, Plug **plug);
void portfwd_raw_free(Channel *pfchan);
void portfwd_raw_setup(Channel *pfchan, Socket *s, SshChannel *sc);
Move port-forwarding setup out of ssh.c. The tree234 storing currently active port forwardings - both local and remote - now lives in portfwd.c, as does the complicated function that updates it based on a Conf listing the new set of desired forwardings. Local port forwardings are passed to ssh.c via the same route as before - once the listening port receives a connection and portfwd.c knows where it should be directed to (in particular, after the SOCKS exchange, if any), it calls ssh_send_port_open. Remote forwardings are now initiated by calling ssh_rportfwd_alloc, which adds an entry to the rportfwds tree (which _is_ still in ssh.c, and still confusingly sorted by a different criterion depending on SSH protocol version) and sends out the appropriate protocol request. ssh_rportfwd_remove cancels one again, sending a protocol request too. Those functions look enough like ssh_{alloc,remove}_sharing_rportfwd that I've merged those into the new pair as well - now allocating an rportfwd allows you to specify either a destination host/port or a sharing context, and returns a handy pointer you can use to cancel the forwarding later.
2018-09-14 19:04:39 +03:00
Factor out Unix Pageant's socket creation. The code in Pageant that sets up the Unix socket and its containing directory now lives in a separate file, uxagentsock.c, where it will also be callable from the upcoming new SSH server when it wants to create a similar socket for agent forwarding. While I'm at it, I've also added a feature to create a watchdog subprocess that will try to clean up the socket and directory once Pageant itself terminates, in the hope of leaving less cruft lying around /tmp.
2018-10-14 20:48:02 +03:00
Socket *platform_make_agent_socket(Plug *plug, const char *dirprefix,
char **error, char **name);
Refactor the LogContext type. LogContext is now the owner of the logevent() function that back ends and so forth are constantly calling. Previously, logevent was owned by the Frontend, which would store the message into its list for the GUI Event Log dialog (or print it to standard error, or whatever) and then pass it _back_ to LogContext to write to the currently open log file. Now it's the other way round: LogContext gets the message from the back end first, writes it to its log file if it feels so inclined, and communicates it back to the front end. This means that lots of parts of the back end system no longer need to have a pointer to a full-on Frontend; the only thing they needed it for was logging, so now they just have a LogContext (which many of them had to have anyway, e.g. for logging SSH packets or session traffic). LogContext itself also doesn't get a full Frontend pointer any more: it now talks back to the front end via a little vtable of its own called LogPolicy, which contains the method that passes Event Log entries through, the old askappend() function that decides whether to truncate a pre-existing log file, and an emergency function for printing an especially prominent message if the log file can't be created. One minor nice effect of this is that console and GUI apps can implement that last function subtly differently, so that Unix console apps can write it with a plain \n instead of the \r\n (harmless but inelegant) that the old centralised implementation generated. One other consequence of this is that the LogContext has to be provided to backend_init() so that it's available to backends from the instant of creation, rather than being provided via a separate API call a couple of function calls later, because backends have typically started doing things that need logging (like making network connections) before the call to backend_provide_logctx. Fortunately, there's no case in the whole code base where we don't already have logctx by the time we make a backend (so I don't actually remember why I ever delayed providing one). So that shortens the backend API by one function, which is always nice. While I'm tidying up, I've also moved the printf-style logeventf() and the handy logevent_and_free() into logging.c, instead of having copies of them scattered around other places. This has also let me remove some stub functions from a couple of outlying applications like Pageant. Finally, I've removed the pointless "_tag" at the end of LogContext's official struct name.
2018-10-10 21:26:18 +03:00
LogContext *ssh_get_logctx(Ssh *ssh);
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
Move most of ssh.c out into separate source files. I've tried to separate out as many individually coherent changes from this work as I could into their own commits, but here's where I run out and have to commit the rest of this major refactoring as a big-bang change. Most of ssh.c is now no longer in ssh.c: all five of the main coroutines that handle layers of the SSH-1 and SSH-2 protocols now each have their own source file to live in, and a lot of the supporting functions have moved into the appropriate one of those too. The new abstraction is a vtable called 'PacketProtocolLayer', which has an input and output packet queue. Each layer's main coroutine is invoked from the method ssh_ppl_process_queue(), which is usually (though not exclusively) triggered automatically when things are pushed on the input queue. In SSH-2, the base layer is the transport protocol, and it contains a pair of subsidiary queues by which it passes some of its packets to the higher SSH-2 layers - first userauth and then connection, which are peers at the same level, with the former abdicating in favour of the latter at the appropriate moment. SSH-1 is simpler: the whole login phase of the protocol (crypto setup and authentication) is all in one module, and since SSH-1 has no repeat key exchange, that setup layer abdicates in favour of the connection phase when it's done. ssh.c itself is now about a tenth of its old size (which all by itself is cause for celebration!). Its main job is to set up all the layers, hook them up to each other and to the BPP, and to funnel data back and forth between that collection of modules and external things such as the network and the terminal. Once it's set up a collection of packet protocol layers, it communicates with them partly by calling methods of the base layer (and if that's ssh2transport then it will delegate some functionality to the corresponding methods of its higher layer), and partly by talking directly to the connection layer no matter where it is in the stack by means of the separate ConnectionLayer vtable which I introduced in commit 8001dd4cb, and to which I've now added quite a few extra methods replacing services that used to be internal function calls within ssh.c. (One effect of this is that the SSH-1 and SSH-2 channel storage is now no longer shared - there are distinct struct types ssh1_channel and ssh2_channel. That means a bit more code duplication, but on the plus side, a lot fewer confusing conditionals in the middle of half-shared functions, and less risk of a piece of SSH-1 escaping into SSH-2 or vice versa, which I remember has happened at least once in the past.) The bulk of this commit introduces the five new source files, their common header sshppl.h and some shared supporting routines in sshcommon.c, and rewrites nearly all of ssh.c itself. But it also includes a couple of other changes that I couldn't separate easily enough: Firstly, there's a new handling for socket EOF, in which ssh.c sets an 'input_eof' flag in the BPP, and that responds by checking a flag that tells it whether to report the EOF as an error or not. (This is the main reason for those new BPP_READ / BPP_WAITFOR macros - they can check the EOF flag every time the coroutine is resumed.) Secondly, the error reporting itself is changed around again. I'd expected to put some data fields in the public PacketProtocolLayer structure that it could set to report errors in the same way as the BPPs have been doing, but in the end, I decided propagating all those data fields around was a pain and that even the BPPs shouldn't have been doing it that way. So I've reverted to a system where everything calls back to functions in ssh.c itself to report any connection- ending condition. But there's a new family of those functions, categorising the possible such conditions by semantics, and each one has a different set of detailed effects (e.g. how rudely to close the network connection, what exit status should be passed back to the whole application, whether to send a disconnect message and/or display a GUI error box). I don't expect this to be immediately perfect: of course, the code has been through a big upheaval, new bugs are expected, and I haven't been able to do a full job of testing (e.g. I haven't tested every auth or kex method). But I've checked that it _basically_ works - both SSH protocols, all the different kinds of forwarding channel, more than one auth method, Windows and Linux, connection sharing - and I think it's now at the point where the easiest way to find further bugs is to let it out into the wild and see what users can spot.
2018-09-24 20:28:16 +03:00
/* Communications back to ssh.c from connection layers */
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 21:10:23 +03:00
void ssh_throttle_conn(Ssh *ssh, int adjust);
void ssh_got_exitcode(Ssh *ssh, int status);
void ssh_ldisc_update(Ssh *ssh);
void ssh_got_fallback_cmd(Ssh *ssh);
Move most of ssh.c out into separate source files. I've tried to separate out as many individually coherent changes from this work as I could into their own commits, but here's where I run out and have to commit the rest of this major refactoring as a big-bang change. Most of ssh.c is now no longer in ssh.c: all five of the main coroutines that handle layers of the SSH-1 and SSH-2 protocols now each have their own source file to live in, and a lot of the supporting functions have moved into the appropriate one of those too. The new abstraction is a vtable called 'PacketProtocolLayer', which has an input and output packet queue. Each layer's main coroutine is invoked from the method ssh_ppl_process_queue(), which is usually (though not exclusively) triggered automatically when things are pushed on the input queue. In SSH-2, the base layer is the transport protocol, and it contains a pair of subsidiary queues by which it passes some of its packets to the higher SSH-2 layers - first userauth and then connection, which are peers at the same level, with the former abdicating in favour of the latter at the appropriate moment. SSH-1 is simpler: the whole login phase of the protocol (crypto setup and authentication) is all in one module, and since SSH-1 has no repeat key exchange, that setup layer abdicates in favour of the connection phase when it's done. ssh.c itself is now about a tenth of its old size (which all by itself is cause for celebration!). Its main job is to set up all the layers, hook them up to each other and to the BPP, and to funnel data back and forth between that collection of modules and external things such as the network and the terminal. Once it's set up a collection of packet protocol layers, it communicates with them partly by calling methods of the base layer (and if that's ssh2transport then it will delegate some functionality to the corresponding methods of its higher layer), and partly by talking directly to the connection layer no matter where it is in the stack by means of the separate ConnectionLayer vtable which I introduced in commit 8001dd4cb, and to which I've now added quite a few extra methods replacing services that used to be internal function calls within ssh.c. (One effect of this is that the SSH-1 and SSH-2 channel storage is now no longer shared - there are distinct struct types ssh1_channel and ssh2_channel. That means a bit more code duplication, but on the plus side, a lot fewer confusing conditionals in the middle of half-shared functions, and less risk of a piece of SSH-1 escaping into SSH-2 or vice versa, which I remember has happened at least once in the past.) The bulk of this commit introduces the five new source files, their common header sshppl.h and some shared supporting routines in sshcommon.c, and rewrites nearly all of ssh.c itself. But it also includes a couple of other changes that I couldn't separate easily enough: Firstly, there's a new handling for socket EOF, in which ssh.c sets an 'input_eof' flag in the BPP, and that responds by checking a flag that tells it whether to report the EOF as an error or not. (This is the main reason for those new BPP_READ / BPP_WAITFOR macros - they can check the EOF flag every time the coroutine is resumed.) Secondly, the error reporting itself is changed around again. I'd expected to put some data fields in the public PacketProtocolLayer structure that it could set to report errors in the same way as the BPPs have been doing, but in the end, I decided propagating all those data fields around was a pain and that even the BPPs shouldn't have been doing it that way. So I've reverted to a system where everything calls back to functions in ssh.c itself to report any connection- ending condition. But there's a new family of those functions, categorising the possible such conditions by semantics, and each one has a different set of detailed effects (e.g. how rudely to close the network connection, what exit status should be passed back to the whole application, whether to send a disconnect message and/or display a GUI error box). I don't expect this to be immediately perfect: of course, the code has been through a big upheaval, new bugs are expected, and I haven't been able to do a full job of testing (e.g. I haven't tested every auth or kex method). But I've checked that it _basically_ works - both SSH protocols, all the different kinds of forwarding channel, more than one auth method, Windows and Linux, connection sharing - and I think it's now at the point where the easiest way to find further bugs is to let it out into the wild and see what users can spot.
2018-09-24 20:28:16 +03:00
Work around unhelpful GTK event ordering. If the SSH socket is readable, GTK will preferentially give us a callback to read from it rather than calling its idle functions. That means the ssh->in_raw bufchain can just keep accumulating data, and the callback that gets the BPP to take data back off that bufchain will never be called at all. The solution is to use sk_set_frozen after a certain point, to stop reading further data from the socket (and, more importantly, disable GTK's I/O callback for that fd) until we've had a chance to process some backlog, and then unfreeze the socket again afterwards. Annoyingly, that means adding a _second_ 'frozen' flag to Ssh, because the one we already had has exactly the wrong semantics - it prevents us from _processing_ our backlog, which is the last thing we want if the entire problem is that we need that backlog to get smaller! So now there are two frozen flags, and a big comment explaining the difference.
2019-02-06 09:52:25 +03:00
/* Communications back to ssh.c from the BPP */
void ssh_conn_processed_data(Ssh *ssh);
Call ssh_check_frozen when BPP consumes input. In commit 0f405ae8a, I arranged to stop reading from the SSH connection if the in_raw bufchain got too big. But in at least some tools (this bit me just now with PSCP), nothing actually calls ssh_check_frozen again when the bufchain clears, so it stays frozen. Now ssh_check_frozen is non-static, and all the BPP implementations call it whenever they consume data from ssh->in_raw.
2019-02-17 22:06:03 +03:00
void ssh_check_frozen(Ssh *ssh);
Work around unhelpful GTK event ordering. If the SSH socket is readable, GTK will preferentially give us a callback to read from it rather than calling its idle functions. That means the ssh->in_raw bufchain can just keep accumulating data, and the callback that gets the BPP to take data back off that bufchain will never be called at all. The solution is to use sk_set_frozen after a certain point, to stop reading further data from the socket (and, more importantly, disable GTK's I/O callback for that fd) until we've had a chance to process some backlog, and then unfreeze the socket again afterwards. Annoyingly, that means adding a _second_ 'frozen' flag to Ssh, because the one we already had has exactly the wrong semantics - it prevents us from _processing_ our backlog, which is the last thing we want if the entire problem is that we need that backlog to get smaller! So now there are two frozen flags, and a big comment explaining the difference.
2019-02-06 09:52:25 +03:00
Move most of ssh.c out into separate source files. I've tried to separate out as many individually coherent changes from this work as I could into their own commits, but here's where I run out and have to commit the rest of this major refactoring as a big-bang change. Most of ssh.c is now no longer in ssh.c: all five of the main coroutines that handle layers of the SSH-1 and SSH-2 protocols now each have their own source file to live in, and a lot of the supporting functions have moved into the appropriate one of those too. The new abstraction is a vtable called 'PacketProtocolLayer', which has an input and output packet queue. Each layer's main coroutine is invoked from the method ssh_ppl_process_queue(), which is usually (though not exclusively) triggered automatically when things are pushed on the input queue. In SSH-2, the base layer is the transport protocol, and it contains a pair of subsidiary queues by which it passes some of its packets to the higher SSH-2 layers - first userauth and then connection, which are peers at the same level, with the former abdicating in favour of the latter at the appropriate moment. SSH-1 is simpler: the whole login phase of the protocol (crypto setup and authentication) is all in one module, and since SSH-1 has no repeat key exchange, that setup layer abdicates in favour of the connection phase when it's done. ssh.c itself is now about a tenth of its old size (which all by itself is cause for celebration!). Its main job is to set up all the layers, hook them up to each other and to the BPP, and to funnel data back and forth between that collection of modules and external things such as the network and the terminal. Once it's set up a collection of packet protocol layers, it communicates with them partly by calling methods of the base layer (and if that's ssh2transport then it will delegate some functionality to the corresponding methods of its higher layer), and partly by talking directly to the connection layer no matter where it is in the stack by means of the separate ConnectionLayer vtable which I introduced in commit 8001dd4cb, and to which I've now added quite a few extra methods replacing services that used to be internal function calls within ssh.c. (One effect of this is that the SSH-1 and SSH-2 channel storage is now no longer shared - there are distinct struct types ssh1_channel and ssh2_channel. That means a bit more code duplication, but on the plus side, a lot fewer confusing conditionals in the middle of half-shared functions, and less risk of a piece of SSH-1 escaping into SSH-2 or vice versa, which I remember has happened at least once in the past.) The bulk of this commit introduces the five new source files, their common header sshppl.h and some shared supporting routines in sshcommon.c, and rewrites nearly all of ssh.c itself. But it also includes a couple of other changes that I couldn't separate easily enough: Firstly, there's a new handling for socket EOF, in which ssh.c sets an 'input_eof' flag in the BPP, and that responds by checking a flag that tells it whether to report the EOF as an error or not. (This is the main reason for those new BPP_READ / BPP_WAITFOR macros - they can check the EOF flag every time the coroutine is resumed.) Secondly, the error reporting itself is changed around again. I'd expected to put some data fields in the public PacketProtocolLayer structure that it could set to report errors in the same way as the BPPs have been doing, but in the end, I decided propagating all those data fields around was a pain and that even the BPPs shouldn't have been doing it that way. So I've reverted to a system where everything calls back to functions in ssh.c itself to report any connection- ending condition. But there's a new family of those functions, categorising the possible such conditions by semantics, and each one has a different set of detailed effects (e.g. how rudely to close the network connection, what exit status should be passed back to the whole application, whether to send a disconnect message and/or display a GUI error box). I don't expect this to be immediately perfect: of course, the code has been through a big upheaval, new bugs are expected, and I haven't been able to do a full job of testing (e.g. I haven't tested every auth or kex method). But I've checked that it _basically_ works - both SSH protocols, all the different kinds of forwarding channel, more than one auth method, Windows and Linux, connection sharing - and I think it's now at the point where the easiest way to find further bugs is to let it out into the wild and see what users can spot.
2018-09-24 20:28:16 +03:00
/* Functions to abort the connection, for various reasons. */
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 21:10:23 +03:00
void ssh_remote_error(Ssh *ssh, const char *fmt, ...);
void ssh_remote_eof(Ssh *ssh, const char *fmt, ...);
void ssh_proto_error(Ssh *ssh, const char *fmt, ...);
void ssh_sw_abort(Ssh *ssh, const char *fmt, ...);
void ssh_user_close(Ssh *ssh, const char *fmt, ...);
Move most of ssh.c out into separate source files. I've tried to separate out as many individually coherent changes from this work as I could into their own commits, but here's where I run out and have to commit the rest of this major refactoring as a big-bang change. Most of ssh.c is now no longer in ssh.c: all five of the main coroutines that handle layers of the SSH-1 and SSH-2 protocols now each have their own source file to live in, and a lot of the supporting functions have moved into the appropriate one of those too. The new abstraction is a vtable called 'PacketProtocolLayer', which has an input and output packet queue. Each layer's main coroutine is invoked from the method ssh_ppl_process_queue(), which is usually (though not exclusively) triggered automatically when things are pushed on the input queue. In SSH-2, the base layer is the transport protocol, and it contains a pair of subsidiary queues by which it passes some of its packets to the higher SSH-2 layers - first userauth and then connection, which are peers at the same level, with the former abdicating in favour of the latter at the appropriate moment. SSH-1 is simpler: the whole login phase of the protocol (crypto setup and authentication) is all in one module, and since SSH-1 has no repeat key exchange, that setup layer abdicates in favour of the connection phase when it's done. ssh.c itself is now about a tenth of its old size (which all by itself is cause for celebration!). Its main job is to set up all the layers, hook them up to each other and to the BPP, and to funnel data back and forth between that collection of modules and external things such as the network and the terminal. Once it's set up a collection of packet protocol layers, it communicates with them partly by calling methods of the base layer (and if that's ssh2transport then it will delegate some functionality to the corresponding methods of its higher layer), and partly by talking directly to the connection layer no matter where it is in the stack by means of the separate ConnectionLayer vtable which I introduced in commit 8001dd4cb, and to which I've now added quite a few extra methods replacing services that used to be internal function calls within ssh.c. (One effect of this is that the SSH-1 and SSH-2 channel storage is now no longer shared - there are distinct struct types ssh1_channel and ssh2_channel. That means a bit more code duplication, but on the plus side, a lot fewer confusing conditionals in the middle of half-shared functions, and less risk of a piece of SSH-1 escaping into SSH-2 or vice versa, which I remember has happened at least once in the past.) The bulk of this commit introduces the five new source files, their common header sshppl.h and some shared supporting routines in sshcommon.c, and rewrites nearly all of ssh.c itself. But it also includes a couple of other changes that I couldn't separate easily enough: Firstly, there's a new handling for socket EOF, in which ssh.c sets an 'input_eof' flag in the BPP, and that responds by checking a flag that tells it whether to report the EOF as an error or not. (This is the main reason for those new BPP_READ / BPP_WAITFOR macros - they can check the EOF flag every time the coroutine is resumed.) Secondly, the error reporting itself is changed around again. I'd expected to put some data fields in the public PacketProtocolLayer structure that it could set to report errors in the same way as the BPPs have been doing, but in the end, I decided propagating all those data fields around was a pain and that even the BPPs shouldn't have been doing it that way. So I've reverted to a system where everything calls back to functions in ssh.c itself to report any connection- ending condition. But there's a new family of those functions, categorising the possible such conditions by semantics, and each one has a different set of detailed effects (e.g. how rudely to close the network connection, what exit status should be passed back to the whole application, whether to send a disconnect message and/or display a GUI error box). I don't expect this to be immediately perfect: of course, the code has been through a big upheaval, new bugs are expected, and I haven't been able to do a full job of testing (e.g. I haven't tested every auth or kex method). But I've checked that it _basically_ works - both SSH protocols, all the different kinds of forwarding channel, more than one auth method, Windows and Linux, connection sharing - and I think it's now at the point where the easiest way to find further bugs is to let it out into the wild and see what users can spot.
2018-09-24 20:28:16 +03:00
Add encryption selection, and Blowfish as second option [originally from svn r175]
1999-07-06 23:42:57 +04:00
#define SSH_CIPHER_IDEA 1
Single-DES encryption, patch courtesy of Murphy Lam [originally from svn r253]
1999-10-25 12:59:40 +04:00
#define SSH_CIPHER_DES 2
Add encryption selection, and Blowfish as second option [originally from svn r175]
1999-07-06 23:42:57 +04:00
#define SSH_CIPHER_3DES 3
#define SSH_CIPHER_BLOWFISH 6
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 09:51:44 +03:00
struct ssh_key {
const ssh_keyalg *vt;
};
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03: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 09:51:44 +03:00
struct RSAKey {
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 16:02:13 +03:00
int bits;
int bytes;
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 16:53:41 +03:00
mp_int *modulus;
mp_int *exponent;
mp_int *private_exponent;
mp_int *p;
mp_int *q;
mp_int *iqmp;
Preliminary support for RSA user authentication in SSH2! Most of the error messages are currently wrong, and Pageant doesn't yet support the new key type, and I haven't thoroughly tested that falling back to password authentication and trying invalid keys etc all work. But what I have here has successfully performed a public key authentication, so it's working to at least some extent. [originally from svn r973]
2001-03-03 14:54:34 +03:00
char *comment;
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
ssh_key sshk;
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 09:51:44 +03:00
};
RSA key generation routines, and the bignum enhancements required to support them. A key generation tool will be forthcoming soon. [originally from svn r712]
2000-10-18 19:00:36 +04:00
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
struct dss_key {
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 16:53:41 +03:00
mp_int *p, *q, *g, *y, *x;
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
ssh_key sshk;
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
};
Elliptic-curve cryptography support. This provides support for ECDSA public keys, for both hosts and users, and also ECDH key exchange. Supported curves are currently just the three NIST curves required by RFC 5656.
2014-11-01 12:45:20 +03:00
struct ec_curve;
Support ECDH key exchange using the 'curve25519' curve. This is the kex protocol id "curve25519-sha256@libssh.org", so called because it's over the prime field of order 2^255 - 19. Arithmetic in this curve is done using the Montgomery representation, rather than the Weierstrass representation. So 'struct ec_curve' has grown a discriminant field and a union of subtypes.
2015-05-09 17:02:52 +03:00
/* Weierstrass form curve */
struct ec_wcurve
{
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 16:53:41 +03:00
WeierstrassCurve *wc;
WeierstrassPoint *G;
mp_int *G_order;
Support ECDH key exchange using the 'curve25519' curve. This is the kex protocol id "curve25519-sha256@libssh.org", so called because it's over the prime field of order 2^255 - 19. Arithmetic in this curve is done using the Montgomery representation, rather than the Weierstrass representation. So 'struct ec_curve' has grown a discriminant field and a union of subtypes.
2015-05-09 17:02:52 +03:00
};
/* Montgomery form curve */
struct ec_mcurve
{
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 16:53:41 +03:00
MontgomeryCurve *mc;
MontgomeryPoint *G;
Support ECDH key exchange using the 'curve25519' curve. This is the kex protocol id "curve25519-sha256@libssh.org", so called because it's over the prime field of order 2^255 - 19. Arithmetic in this curve is done using the Montgomery representation, rather than the Weierstrass representation. So 'struct ec_curve' has grown a discriminant field and a union of subtypes.
2015-05-09 17:02:52 +03:00
};
Support public keys using the "ssh-ed25519" method. This introduces a third system of elliptic curve representation and arithmetic, namely Edwards form.
2015-05-09 17:02:54 +03:00
/* Edwards form curve */
struct ec_ecurve
{
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 16:53:41 +03:00
EdwardsCurve *ec;
EdwardsPoint *G;
mp_int *G_order;
Support public keys using the "ssh-ed25519" method. This introduces a third system of elliptic curve representation and arithmetic, namely Edwards form.
2015-05-09 17:02:54 +03:00
};
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 16:53:41 +03:00
typedef enum EllipticCurveType {
EC_WEIERSTRASS, EC_MONTGOMERY, EC_EDWARDS
} EllipticCurveType;
Elliptic-curve cryptography support. This provides support for ECDSA public keys, for both hosts and users, and also ECDH key exchange. Supported curves are currently just the three NIST curves required by RFC 5656.
2014-11-01 12:45:20 +03:00
struct ec_curve {
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 16:53:41 +03:00
EllipticCurveType type;
Log which elliptic curve we're using for ECDH kex. It seems like quite an important thing to mention in the event log! Suppose there's a bug affecting only one curve, for example? Fixed- group Diffie-Hellman has always logged the group, but the ECDH log message just told you the hash and not also the curve. To implement this, I've added a 'textname' field to all elliptic curves, whether they're used for kex or signing or both, suitable for use in this log message and any others we might find a need for in future.
2015-05-19 10:42:23 +03:00
/* 'name' is the identifier of the curve when it has to appear in
* wire protocol encodings, as it does in e.g. the public key and
* signature formats for NIST curves. Curves which do not format
* their keys or signatures in this way just have name==NULL.
*
* 'textname' is non-NULL for all curves, and is a human-readable
* identification suitable for putting in log messages. */
const char *name, *textname;
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 16:53:41 +03:00
size_t fieldBits, fieldBytes;
mp_int *p;
Support ECDH key exchange using the 'curve25519' curve. This is the kex protocol id "curve25519-sha256@libssh.org", so called because it's over the prime field of order 2^255 - 19. Arithmetic in this curve is done using the Montgomery representation, rather than the Weierstrass representation. So 'struct ec_curve' has grown a discriminant field and a union of subtypes.
2015-05-09 17:02:52 +03:00
union {
struct ec_wcurve w;
struct ec_mcurve m;
Support public keys using the "ssh-ed25519" method. This introduces a third system of elliptic curve representation and arithmetic, namely Edwards form.
2015-05-09 17:02:54 +03:00
struct ec_ecurve e;
Support ECDH key exchange using the 'curve25519' curve. This is the kex protocol id "curve25519-sha256@libssh.org", so called because it's over the prime field of order 2^255 - 19. Arithmetic in this curve is done using the Montgomery representation, rather than the Weierstrass representation. So 'struct ec_curve' has grown a discriminant field and a union of subtypes.
2015-05-09 17:02:52 +03:00
};
Elliptic-curve cryptography support. This provides support for ECDSA public keys, for both hosts and users, and also ECDH key exchange. Supported curves are currently just the three NIST curves required by RFC 5656.
2014-11-01 12:45:20 +03:00
};
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
const ssh_keyalg *ec_alg_by_oid(int len, const void *oid,
Clean up elliptic curve selection and naming. The ec_name_to_curve and ec_curve_to_name functions shouldn't really have had to exist at all: whenever any part of the PuTTY codebase starts using sshecc.c, it's starting from an ssh_signkey or ssh_kex pointer already found by some other means. So if we make sure not to lose that pointer, we should never need to do any string-based lookups to find the curve we want, and conversely, when we need to know the name of our curve or our algorithm, we should be able to look it up as a straightforward const char * starting from the algorithm pointer. This commit cleans things up so that that is indeed what happens. The ssh_signkey and ssh_kex structures defined in sshecc.c now have 'extra' fields containing pointers to all the necessary stuff; ec_name_to_curve and ec_curve_to_name have been completely removed; struct ec_curve has a string field giving the curve's name (but only for those curves which _have_ a name exposed in the wire protocol, i.e. the three NIST ones); struct ec_key keeps a pointer to the ssh_signkey it started from, and uses that to remember the algorithm name rather than reconstructing it from the curve. And I think I've got rid of all the ad-hockery scattered around the code that switches on curve->fieldBits or manually constructs curve names using stuff like sprintf("nistp%d"); the only remaining switch on fieldBits (necessary because that's the UI for choosing a curve in PuTTYgen) is at least centralised into one place in sshecc.c. One user-visible result is that the format of ed25519 host keys in the registry has changed: there's now no curve name prefix on them, because I think it's not really right to make up a name to use. So any early adopters who've been using snapshot PuTTY in the last week will be inconvenienced; sorry about that.
2015-05-15 12:13:05 +03:00
const struct ec_curve **curve);
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
const unsigned char *ec_alg_oid(const ssh_keyalg *alg, int *oidlen);
Polish up the PuTTYgen user interface for ECC key types. Jacob pointed out that a free-text field for entering a key size in bits is all very well for key types where we actually _can_ generate a key to a size of your choice, but less useful for key types where there are only three (or one) legal values for the field, especially if we don't _say_ what they are. So I've revamped the UI a bit: now, in ECDSA mode, you get a dropdown list selector showing the available elliptic curves (and they're even named, rather than just given by bit count), and in ED25519 mode even that disappears. The curve selector for ECDSA and the bits selector for RSA/DSA are independent controls, so each one remembers its last known value even while temporarily hidden in favour of the other. The actual generation function still expects a bit count rather than an actual curve or algorithm ID, so the easiest way to actually arrange to populate the drop-down list was to have an array of bit counts exposed by sshecc.c. That's a bit ugly, but there we go. One small functional change: if you enter an absurdly low value into the RSA/DSA bit count box (under 256), PuTTYgen used to give a warning and reset it to 256. Now it resets it to the default key length of 2048, basically because I was touching that code anyway to change a variable name and just couldn't bring myself to leave it in a state where it intentionally chose such an utterly useless key size. Of course this doesn't prevent generation of 256-bit keys if someone still really wants one - it just means they don't get one selected as the result of a typo.
2016-03-25 10:53:06 +03:00
extern const int ec_nist_curve_lengths[], n_ec_nist_curve_lengths;
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 22:23:19 +03:00
bool ec_nist_alg_and_curve_by_bits(int bits,
const struct ec_curve **curve,
const ssh_keyalg **alg);
bool ec_ed_alg_and_curve_by_bits(int bits,
const struct ec_curve **curve,
const ssh_keyalg **alg);
Elliptic-curve cryptography support. This provides support for ECDSA public keys, for both hosts and users, and also ECDH key exchange. Supported curves are currently just the three NIST curves required by RFC 5656.
2014-11-01 12:45:20 +03:00
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 16:53:41 +03:00
struct ecdsa_key {
const struct ec_curve *curve;
WeierstrassPoint *publicKey;
mp_int *privateKey;
ssh_key sshk;
};
struct eddsa_key {
const struct ec_curve *curve;
EdwardsPoint *publicKey;
mp_int *privateKey;
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
ssh_key sshk;
Elliptic-curve cryptography support. This provides support for ECDSA public keys, for both hosts and users, and also ECDH key exchange. Supported curves are currently just the three NIST curves required by RFC 5656.
2014-11-01 12:45:20 +03:00
};
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 16:53:41 +03:00
WeierstrassPoint *ecdsa_public(mp_int *private_key, const ssh_keyalg *alg);
EdwardsPoint *eddsa_public(mp_int *private_key, const ssh_keyalg *alg);
Support ECDH key exchange using the 'curve25519' curve. This is the kex protocol id "curve25519-sha256@libssh.org", so called because it's over the prime field of order 2^255 - 19. Arithmetic in this curve is done using the Montgomery representation, rather than the Weierstrass representation. So 'struct ec_curve' has grown a discriminant field and a union of subtypes.
2015-05-09 17:02:52 +03:00
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 10:22:44 +03:00
/*
* SSH-1 never quite decided which order to store the two components
* of an RSA key. During connection setup, the server sends its host
* and server keys with the exponent first; private key files store
* the modulus first. The agent protocol is even more confusing,
* because the client specifies a key to the server in one order and
* the server lists the keys it knows about in the other order!
*/
typedef enum { RSA_SSH1_EXPONENT_FIRST, RSA_SSH1_MODULUS_FIRST } RsaSsh1Order;
Rewrite SSH-1 RSA handling functions using BinarySource. The SSH-1 RSA key reading functions now have BinarySource-shaped get_* forms, although for the moment I'm still supporting the old API as a wrapper on the new one, because I haven't switched over the client code yet. Also, rsa_public_blob_len uses the new system internally, although its API is unchanged.
2018-05-27 23:51:36 +03:00
void BinarySource_get_rsa_ssh1_pub(
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 09:51:44 +03:00
BinarySource *src, RSAKey *result, RsaSsh1Order order);
Rewrite SSH-1 RSA handling functions using BinarySource. The SSH-1 RSA key reading functions now have BinarySource-shaped get_* forms, although for the moment I'm still supporting the old API as a wrapper on the new one, because I haven't switched over the client code yet. Also, rsa_public_blob_len uses the new system internally, although its API is unchanged.
2018-05-27 23:51:36 +03:00
void BinarySource_get_rsa_ssh1_priv(
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 09:51:44 +03:00
BinarySource *src, RSAKey *rsa);
bool rsa_ssh1_encrypt(unsigned char *data, int length, RSAKey *key);
mp_int *rsa_ssh1_decrypt(mp_int *input, RSAKey *key);
bool rsa_ssh1_decrypt_pkcs1(mp_int *input, RSAKey *key, strbuf *outbuf);
char *rsastr_fmt(RSAKey *key);
char *rsa_ssh1_fingerprint(RSAKey *key);
bool rsa_verify(RSAKey *key);
void rsa_ssh1_public_blob(BinarySink *bs, RSAKey *key, RsaSsh1Order order);
Replace more (pointer, length) arg pairs with ptrlen. The abstract method ssh_key_sign(), and the concrete functions ssh_rsakex_newkey() and rsa_ssh1_public_blob_len(), now each take a ptrlen argument in place of a separate pointer and length pair. Partly that's because I'm generally preferring ptrlens these days and it keeps argument lists short and tidy-looking, but mostly it's because it will make those functions easier to wrap in my upcoming test system.
2019-01-02 00:07:48 +03:00
int rsa_ssh1_public_blob_len(ptrlen data);
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 09:51:44 +03:00
void freersapriv(RSAKey *key);
void freersakey(RSAKey *key);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 16:02:13 +03:00
Expose CRC32 to testcrypt, and add tests for it. Finding even semi-official test vectors for this CRC implementation was hard, because it turns out not to _quite_ match any of the well known ones catalogued on the web. Its _polynomial_ is well known, but the combination of details that go alongside it (starting state, post-hashing transformation) are not quite the same as any other hash I know of. After trawling catalogue websites for a while I finally worked out that SSH-1's CRC and RFC 1662's CRC are basically the same except for different choices of starting value and final adjustment. And RFC 1662's CRC is common enough that there _are_ test vectors. So I've renamed the previous crc32_compute function to crc32_ssh1, reflecting that it seems to be its own thing unlike any other CRC; implemented the RFC 1662 CRC as well, as an alternative tiny wrapper on the inner crc32_update function; and exposed all three functions to testcrypt. That lets me run standard test vectors _and_ directed tests of the internal update routine, plus one check that crc32_ssh1 itself does what I expect. While I'm here, I've also modernised the code to use uint32_t in place of unsigned long, and ptrlen instead of separate pointer,length arguments. And I've removed the general primer on CRC theory from the header comment, in favour of the more specifically useful information about _which_ CRC this is and how it matches up to anything else out there. (I've bowed to inevitability and put the directed CRC tests in the 'crypt' class in cryptsuite.py. Of course this is a misnomer, since CRC isn't cryptography, but it falls into the same category in terms of the role it plays in SSH-1, and I didn't feel like making a new pointedly-named 'notreallycrypt' container class just for this :-)
2019-01-14 23:45:19 +03:00
uint32_t crc32_rfc1662(ptrlen data);
uint32_t crc32_ssh1(ptrlen data);
uint32_t crc32_update(uint32_t crc_input, ptrlen data);
Add the CRC32 compensation attack detector that all other SSH clients have had for ages and I forgot about. Of course I've got the version with the buffer overflow fixed! [originally from svn r1535]
2002-01-08 14:57:32 +03:00
/* SSH CRC compensation attack detector */
Expose the structure tag 'crcda_ctx'. This one isn't used in many places, but it's another 'void *' pointer that ought to come with an identifying structure tag.
2018-09-13 15:00:56 +03:00
struct crcda_ctx;
struct crcda_ctx *crcda_make_context(void);
void crcda_free_context(struct crcda_ctx *ctx);
Add tests of the CRC compensation detector. I remembered the existence of that module while I was changing the API of the CRC functions. It's still quite possibly the only code in PuTTY not written specifically _for_ PuTTY, so it definitely deserves a bit of a test suite. In order to expose it through the ptrlen-centric testcrypt system, I've added some missing 'const' in the detector module itself, but otherwise I've left the detector code as it was.
2019-01-15 00:19:38 +03:00
bool detect_attack(struct crcda_ctx *ctx,
const unsigned char *buf, uint32_t len,
const unsigned char *IV);
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 16:02:13 +03:00
Add support for RFC 4432 RSA key exchange, the patch for which has been lying around in my home directory for _years_. [originally from svn r7496]
2007-05-01 02:09:26 +04:00
/*
* SSH2 RSA key exchange functions
*/
Server prep: extra RSA crypto primitives. I've written the decryption side of the PKCS#1 encryption used in SSH-1, and also the RSAES-OAEP system used by SSH-2 RSA kex. Also, the RSA kex structures now each come with an 'extra' pointer giving the minimum key length.
2018-10-21 00:37:51 +03:00
struct ssh_rsa_kex_extra {
int minklen;
};
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 09:51:44 +03:00
RSAKey *ssh_rsakex_newkey(ptrlen data);
void ssh_rsakex_freekey(RSAKey *key);
int ssh_rsakex_klen(RSAKey *key);
Tidy up the API for RSA key exchange. ssh_rsakex_encrypt took an input (pointer, length) pair, which I've replaced with a ptrlen; it also took an _output_ (pointer, length) pair, and then re-computed the right length internally and enforced by assertion that the one passed in matched it. Now it just returns a strbuf of whatever length it computed, which saves the caller having to compute the length at all. Also, both ssh_rsakex_encrypt and ssh_rsakex_decrypt took their arguments in a weird order; I think it looks more sensible to put the RSA key first rather than last, so now they both have the common order (key, hash, input data).
2019-01-02 11:39:16 +03:00
strbuf *ssh_rsakex_encrypt(
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 09:51:44 +03:00
RSAKey *key, const ssh_hashalg *h, ptrlen plaintext);
Tidy up the API for RSA key exchange. ssh_rsakex_encrypt took an input (pointer, length) pair, which I've replaced with a ptrlen; it also took an _output_ (pointer, length) pair, and then re-computed the right length internally and enforced by assertion that the one passed in matched it. Now it just returns a strbuf of whatever length it computed, which saves the caller having to compute the length at all. Also, both ssh_rsakex_encrypt and ssh_rsakex_decrypt took their arguments in a weird order; I think it looks more sensible to put the RSA key first rather than last, so now they both have the common order (key, hash, input data).
2019-01-02 11:39:16 +03:00
mp_int *ssh_rsakex_decrypt(
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 09:51:44 +03:00
RSAKey *key, const ssh_hashalg *h, ptrlen ciphertext);
Add support for RFC 4432 RSA key exchange, the patch for which has been lying around in my home directory for _years_. [originally from svn r7496]
2007-05-01 02:09:26 +04:00
Elliptic-curve cryptography support. This provides support for ECDSA public keys, for both hosts and users, and also ECDH key exchange. Supported curves are currently just the three NIST curves required by RFC 5656.
2014-11-01 12:45:20 +03:00
/*
* SSH2 ECDH key exchange functions
*/
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 09:51:44 +03:00
const char *ssh_ecdhkex_curve_textname(const ssh_kex *kex);
ecdh_key *ssh_ecdhkex_newkey(const ssh_kex *kex);
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 16:53:41 +03:00
void ssh_ecdhkex_freekey(ecdh_key *key);
void ssh_ecdhkex_getpublic(ecdh_key *key, BinarySink *bs);
mp_int *ssh_ecdhkex_getkey(ecdh_key *key, ptrlen remoteKey);
Elliptic-curve cryptography support. This provides support for ECDSA public keys, for both hosts and users, and also ECDH key exchange. Supported curves are currently just the three NIST curves required by RFC 5656.
2014-11-01 12:45:20 +03:00
Factor out the DSA deterministic k generator. It's now a separate function, which you call with an identifying string to be hashed into the generation of x. The idea is that other DSA-like signature algorithms can reuse the same function, with a different id string. As a minor refinement, we now also never return k=1.
2014-11-01 22:48:48 +03:00
/*
* Helper function for k generation in DSA, reused in ECDSA
*/
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 16:53:41 +03:00
mp_int *dss_gen_k(const char *id_string,
mp_int *modulus, mp_int *private_key,
unsigned char *digest, int digest_len);
Factor out the DSA deterministic k generator. It's now a separate function, which you call with an identifying string to be hashed into the generation of x. The idea is that other DSA-like signature algorithms can reuse the same function, with a different id string. As a minor refinement, we now also never return k=1.
2014-11-01 22:48:48 +03:00
Merge the ssh1_cipher type into ssh2_cipher. The aim of this reorganisation is to make it easier to test all the ciphers in PuTTY in a uniform way. It was inconvenient that there were two separate vtable systems for the ciphers used in SSH-1 and SSH-2 with different functionality. Now there's only one type, called ssh_cipher. But really it's the old ssh2_cipher, just renamed: I haven't made any changes to the API on the SSH-2 side. Instead, I've removed ssh1_cipher completely, and adapted the SSH-1 BPP to use the SSH-2 style API. (The relevant differences are that ssh1_cipher encapsulated both the sending and receiving directions in one object - so now ssh1bpp has to make a separate cipher instance per direction - and that ssh1_cipher automatically initialised the IV to all zeroes, which ssh1bpp now has to do by hand.) The previous ssh1_cipher vtable for single-DES has been removed completely, because when converted into the new API it became identical to the SSH-2 single-DES vtable; so now there's just one vtable for DES-CBC which works in both protocols. The other two SSH-1 ciphers each had to stay separate, because 3DES is completely different between SSH-1 and SSH-2 (three layers of CBC structure versus one), and Blowfish varies in endianness and key length between the two. (Actually, while I'm here, I've only just noticed that the SSH-1 Blowfish cipher mis-describes itself in log messages as Blowfish-128. In fact it passes the whole of the input key buffer, which has length SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually Blowfish-256, and has been all along!)
2019-01-17 21:06:08 +03:00
struct ssh_cipher {
const ssh_cipheralg *vt;
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 09:51:44 +03:00
};
Turn SSH-2 ciphers into a classoid. This is more or less the same job as the SSH-1 case, only more extensive, because we have a wider range of ciphers. I'm a bit disappointed about the AES case, in particular, because I feel as if it ought to have been possible to arrange to combine this layer of vtable dispatch with the subsidiary one that selects between hardware and software implementations of the underlying cipher. I may come back later and have another try at that, in fact.
2018-09-13 16:43:04 +03:00
Merge the ssh1_cipher type into ssh2_cipher. The aim of this reorganisation is to make it easier to test all the ciphers in PuTTY in a uniform way. It was inconvenient that there were two separate vtable systems for the ciphers used in SSH-1 and SSH-2 with different functionality. Now there's only one type, called ssh_cipher. But really it's the old ssh2_cipher, just renamed: I haven't made any changes to the API on the SSH-2 side. Instead, I've removed ssh1_cipher completely, and adapted the SSH-1 BPP to use the SSH-2 style API. (The relevant differences are that ssh1_cipher encapsulated both the sending and receiving directions in one object - so now ssh1bpp has to make a separate cipher instance per direction - and that ssh1_cipher automatically initialised the IV to all zeroes, which ssh1bpp now has to do by hand.) The previous ssh1_cipher vtable for single-DES has been removed completely, because when converted into the new API it became identical to the SSH-2 single-DES vtable; so now there's just one vtable for DES-CBC which works in both protocols. The other two SSH-1 ciphers each had to stay separate, because 3DES is completely different between SSH-1 and SSH-2 (three layers of CBC structure versus one), and Blowfish varies in endianness and key length between the two. (Actually, while I'm here, I've only just noticed that the SSH-1 Blowfish cipher mis-describes itself in log messages as Blowfish-128. In fact it passes the whole of the input key buffer, which has length SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually Blowfish-256, and has been all along!)
2019-01-17 21:06:08 +03:00
struct ssh_cipheralg {
ssh_cipher *(*new)(const ssh_cipheralg *alg);
void (*free)(ssh_cipher *);
void (*setiv)(ssh_cipher *, const void *iv);
void (*setkey)(ssh_cipher *, const void *key);
void (*encrypt)(ssh_cipher *, void *blk, int len);
void (*decrypt)(ssh_cipher *, void *blk, int len);
Allow a cipher to specify encryption of the packet length. No cipher uses this facility yet, but one shortly will.
2015-06-07 14:51:24 +03:00
/* Ignored unless SSH_CIPHER_SEPARATE_LENGTH flag set */
Merge the ssh1_cipher type into ssh2_cipher. The aim of this reorganisation is to make it easier to test all the ciphers in PuTTY in a uniform way. It was inconvenient that there were two separate vtable systems for the ciphers used in SSH-1 and SSH-2 with different functionality. Now there's only one type, called ssh_cipher. But really it's the old ssh2_cipher, just renamed: I haven't made any changes to the API on the SSH-2 side. Instead, I've removed ssh1_cipher completely, and adapted the SSH-1 BPP to use the SSH-2 style API. (The relevant differences are that ssh1_cipher encapsulated both the sending and receiving directions in one object - so now ssh1bpp has to make a separate cipher instance per direction - and that ssh1_cipher automatically initialised the IV to all zeroes, which ssh1bpp now has to do by hand.) The previous ssh1_cipher vtable for single-DES has been removed completely, because when converted into the new API it became identical to the SSH-2 single-DES vtable; so now there's just one vtable for DES-CBC which works in both protocols. The other two SSH-1 ciphers each had to stay separate, because 3DES is completely different between SSH-1 and SSH-2 (three layers of CBC structure versus one), and Blowfish varies in endianness and key length between the two. (Actually, while I'm here, I've only just noticed that the SSH-1 Blowfish cipher mis-describes itself in log messages as Blowfish-128. In fact it passes the whole of the input key buffer, which has length SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually Blowfish-256, and has been all along!)
2019-01-17 21:06:08 +03:00
void (*encrypt_length)(ssh_cipher *, void *blk, int len,
Turn SSH-2 ciphers into a classoid. This is more or less the same job as the SSH-1 case, only more extensive, because we have a wider range of ciphers. I'm a bit disappointed about the AES case, in particular, because I feel as if it ought to have been possible to arrange to combine this layer of vtable dispatch with the subsidiary one that selects between hardware and software implementations of the underlying cipher. I may come back later and have another try at that, in fact.
2018-09-13 16:43:04 +03:00
unsigned long seq);
Merge the ssh1_cipher type into ssh2_cipher. The aim of this reorganisation is to make it easier to test all the ciphers in PuTTY in a uniform way. It was inconvenient that there were two separate vtable systems for the ciphers used in SSH-1 and SSH-2 with different functionality. Now there's only one type, called ssh_cipher. But really it's the old ssh2_cipher, just renamed: I haven't made any changes to the API on the SSH-2 side. Instead, I've removed ssh1_cipher completely, and adapted the SSH-1 BPP to use the SSH-2 style API. (The relevant differences are that ssh1_cipher encapsulated both the sending and receiving directions in one object - so now ssh1bpp has to make a separate cipher instance per direction - and that ssh1_cipher automatically initialised the IV to all zeroes, which ssh1bpp now has to do by hand.) The previous ssh1_cipher vtable for single-DES has been removed completely, because when converted into the new API it became identical to the SSH-2 single-DES vtable; so now there's just one vtable for DES-CBC which works in both protocols. The other two SSH-1 ciphers each had to stay separate, because 3DES is completely different between SSH-1 and SSH-2 (three layers of CBC structure versus one), and Blowfish varies in endianness and key length between the two. (Actually, while I'm here, I've only just noticed that the SSH-1 Blowfish cipher mis-describes itself in log messages as Blowfish-128. In fact it passes the whole of the input key buffer, which has length SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually Blowfish-256, and has been all along!)
2019-01-17 21:06:08 +03:00
void (*decrypt_length)(ssh_cipher *, void *blk, int len,
Turn SSH-2 ciphers into a classoid. This is more or less the same job as the SSH-1 case, only more extensive, because we have a wider range of ciphers. I'm a bit disappointed about the AES case, in particular, because I feel as if it ought to have been possible to arrange to combine this layer of vtable dispatch with the subsidiary one that selects between hardware and software implementations of the underlying cipher. I may come back later and have another try at that, in fact.
2018-09-13 16:43:04 +03:00
unsigned long seq);
Merge the ssh1_cipher type into ssh2_cipher. The aim of this reorganisation is to make it easier to test all the ciphers in PuTTY in a uniform way. It was inconvenient that there were two separate vtable systems for the ciphers used in SSH-1 and SSH-2 with different functionality. Now there's only one type, called ssh_cipher. But really it's the old ssh2_cipher, just renamed: I haven't made any changes to the API on the SSH-2 side. Instead, I've removed ssh1_cipher completely, and adapted the SSH-1 BPP to use the SSH-2 style API. (The relevant differences are that ssh1_cipher encapsulated both the sending and receiving directions in one object - so now ssh1bpp has to make a separate cipher instance per direction - and that ssh1_cipher automatically initialised the IV to all zeroes, which ssh1bpp now has to do by hand.) The previous ssh1_cipher vtable for single-DES has been removed completely, because when converted into the new API it became identical to the SSH-2 single-DES vtable; so now there's just one vtable for DES-CBC which works in both protocols. The other two SSH-1 ciphers each had to stay separate, because 3DES is completely different between SSH-1 and SSH-2 (three layers of CBC structure versus one), and Blowfish varies in endianness and key length between the two. (Actually, while I'm here, I've only just noticed that the SSH-1 Blowfish cipher mis-describes itself in log messages as Blowfish-128. In fact it passes the whole of the input key buffer, which has length SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually Blowfish-256, and has been all along!)
2019-01-17 21:06:08 +03:00
const char *ssh2_id;
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 18:28:17 +04:00
int blksize;
Split ssh2_cipher's keylen field into two. The revamp of key generation in commit e460f3083 made the assumption that you could decide how many bytes of key material to generate by converting cipher->keylen from bits to bytes. This is a good assumption for all ciphers except DES/3DES: since the SSH DES key setup ignores one bit in every byte of key material it's given, you need more bytes than its keylen field would have you believe. So currently the DES ciphers aren't being keyed correctly. The original keylen field is used for deciding how big a DH group to request, and on that basis I think it still makes sense to keep it reflecting the true entropy of a cipher key. So it turns out we need two _separate_ key length fields per cipher - one for the real entropy, and one for the much more obvious purpose of knowing how much data to ask for from ssh2_mkkey. A compensatory advantage, though, is that we can now measure the latter directly in bytes rather than bits, so we no longer have to faff about with dividing by 8 and rounding up.
2015-09-10 10:10:52 +03:00
/* real_keybits is the number of bits of entropy genuinely used by
* the cipher scheme; it's used for deciding how big a
* Diffie-Hellman group is needed to exchange a key for the
* cipher. */
int real_keybits;
/* padded_keybytes is the number of bytes of key data expected as
* input to the setkey function; it's used for deciding how much
* data needs to be generated from the post-kex generation of key
* material. In a sensible cipher which uses all its key bytes for
* real work, this will just be real_keybits/8, but in DES-type
* ciphers which ignore one bit in each byte, it'll be slightly
* different. */
int padded_keybytes;
Now that we've got at least some SDCTR modes working (and aes256-ctr is our default preferred cipher), add code to inject SSH_MSG_IGNOREs to randomise the IV when using CBC-mode ciphers. Each cipher has a flag to indicate whether it needs this workaround, and the SSH packet output maze has gained some extra complexity to implement it. [originally from svn r5659]
2005-04-23 20:22:51 +04:00
unsigned int flags;
#define SSH_CIPHER_IS_CBC 1
Allow a cipher to specify encryption of the packet length. No cipher uses this facility yet, but one shortly will.
2015-06-07 14:51:24 +03:00
#define SSH_CIPHER_SEPARATE_LENGTH 2
Const-correctness of name fields in struct ssh_*. All the name strings in ssh_cipher, ssh_mac, ssh_hash, ssh_signkey point to compile-time string literals, hence should obviously be const char *. Most of these const-correctness patches are just a mechanical job of adding a 'const' in the one place you need it right now, and then chasing the implications through the code adding further consts until it compiles. But this one has actually shown up a bug: the 'algorithm' output parameter in ssh2_userkey_loadpub was sometimes returning a pointer to a string literal, and sometimes a pointer to dynamically allocated memory, so callers were forced to either sometimes leak memory or sometimes free a bad thing. Now it's consistently dynamically allocated, and should be freed everywhere too.
2015-05-15 12:12:06 +03:00
const char *text_name;
Allow a cipher to override the SSH KEX's choice of MAC. No cipher uses this facility yet, but one shortly will.
2015-06-07 15:40:11 +03:00
/* If set, this takes priority over other MAC. */
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 09:51:44 +03:00
const ssh2_macalg *required_mac;
Complete rewrite of the AES code. sshaes.c is more or less completely changed by this commit. Firstly, I've changed the top-level structure. In the old structure, there were three levels of indirection controlling what an encryption function would actually do: first the ssh2_cipher vtable, then a subsidiary set of function pointers within that to select the software or hardware implementation, and then inside the main encryption function, a switch on the key length to jump into the right place in the unrolled loop of cipher rounds. That was all a bit untidy. So now _all_ of that is done by means of just one selection system, namely the ssh2_cipher vtable. The software and hardware implementations of a given SSH cipher each have their own separate vtable, e.g. ssh2_aes256_sdctr_sw and ssh2_aes256_sdctr_hw; this allows them to have their own completely different state structures too, and not have to try to coexist awkwardly in the same universal AESContext with workaround code to align things correctly. The old implementation-agnostic vtables like ssh2_aes256_sdctr still exist, but now they're mostly empty, containing only the constructor function, which will decide whether AES-NI is currently available and then choose one of the other _real_ vtables to instantiate. As well as the cleaner data representation, this also means the vtables can have different description strings, which means the Event Log will indicate which AES implementation is actually in use; it means the SW and HW vtables are available for testcrypt to use (although actually using them is left for the next commit); and in principle it would also make it easy to support a user override for the automatic SW/HW selection (in case anyone turns out to want one). The AES-NI implementation has been reorganised to fit into the new framework. One thing I've done is to de-optimise the key expansion: instead of having a separate blazingly fast loop-unrolled key setup function for each key length, there's now just one, which uses AES intrinsics for the actual transformations of individual key words, but wraps them in a common loop structure for all the key lengths which has a clear correspondence to the cipher spec. (Sorry to throw away your work there, Pavel, but this isn't an application where key setup really _needs_ to be hugely fast, and I decided I prefer a version I can understand and debug.) The software AES implementation is also completely replaced with one that uses a bit-sliced representation, i.e. the cipher state is split across eight integers in such a way that each logical byte of the state occupies a single bit in each of those integers. The S-box lookup is done by a long string of AND and XOR operations on the eight bits (removing the potential cache side channel from a lookup table), and this representation allows 64 S-box lookups to be done in parallel simply by extending those AND/XOR operations to be bitwise ones on a whole word. So now we can perform four AES encryptions or decryptions in parallel, at least when the cipher mode permits it (which SDCTR and CBC decryption both do). The result is slower than the old implementation, but (a) not by as much as you might think - those parallel S-boxes are surprisingly competitive with 64 separate table lookups; (b) the compensation is that now it should run in constant time with no data-dependent control flow or memory addressing; and (c) in any case the really fast hardware implementation will supersede it for most users.
2019-01-13 16:47:10 +03:00
/* Pointer to any extra data used by a particular implementation. */
const void *extra;
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 18:28:17 +04:00
};
Replace method-dispatch #defines with inline functions. This replaces all the macros like ssh_key_sign() and win_draw_text() which take an object containing a vtable pointer and do the dereferencing to find the actual concrete method to call. Now they're all inline functions, which means more sensible type-checking and more comprehensible error reports when the types go wrong, and also means that there's no risk of double-evaluating the object argument.
2019-02-27 22:44:15 +03:00
static inline ssh_cipher *ssh_cipher_new(const ssh_cipheralg *alg)
{ return alg->new(alg); }
static inline void ssh_cipher_free(ssh_cipher *c)
{ c->vt->free(c); }
static inline void ssh_cipher_setiv(ssh_cipher *c, const void *iv)
{ c->vt->setiv(c, iv); }
static inline void ssh_cipher_setkey(ssh_cipher *c, const void *key)
{ c->vt->setkey(c, key); }
static inline void ssh_cipher_encrypt(ssh_cipher *c, void *blk, int len)
{ c->vt->encrypt(c, blk, len); }
static inline void ssh_cipher_decrypt(ssh_cipher *c, void *blk, int len)
{ c->vt->decrypt(c, blk, len); }
static inline void ssh_cipher_encrypt_length(
ssh_cipher *c, void *blk, int len, unsigned long seq)
{ return c->vt->encrypt_length(c, blk, len, seq); }
static inline void ssh_cipher_decrypt_length(
ssh_cipher *c, void *blk, int len, unsigned long seq)
{ return c->vt->decrypt_length(c, blk, len, seq); }
static inline const struct ssh_cipheralg *ssh_cipher_alg(ssh_cipher *c)
{ return c->vt; }
Turn SSH-2 ciphers into a classoid. This is more or less the same job as the SSH-1 case, only more extensive, because we have a wider range of ciphers. I'm a bit disappointed about the AES case, in particular, because I feel as if it ought to have been possible to arrange to combine this layer of vtable dispatch with the subsidiary one that selects between hardware and software implementations of the underlying cipher. I may come back later and have another try at that, in fact.
2018-09-13 16:43:04 +03:00
Support for selecting AES from the GUI. In the process, I've had to introduce another layer of abstraction in SSH2 ciphers, such that a single `logical cipher' (as desired by a user) can equate to more than one `physical cipher'. This is because AES comes in several key lengths (PuTTY will pick the highest supported by the remote end) and several different SSH2-protocol-level names (aes*-cbc, rijndael*-cbc, and an unofficial one rijndael-cbc@lysator.liu.se). [originally from svn r967]
2001-03-02 16:55:23 +03:00
struct ssh2_ciphers {
int nciphers;
Merge the ssh1_cipher type into ssh2_cipher. The aim of this reorganisation is to make it easier to test all the ciphers in PuTTY in a uniform way. It was inconvenient that there were two separate vtable systems for the ciphers used in SSH-1 and SSH-2 with different functionality. Now there's only one type, called ssh_cipher. But really it's the old ssh2_cipher, just renamed: I haven't made any changes to the API on the SSH-2 side. Instead, I've removed ssh1_cipher completely, and adapted the SSH-1 BPP to use the SSH-2 style API. (The relevant differences are that ssh1_cipher encapsulated both the sending and receiving directions in one object - so now ssh1bpp has to make a separate cipher instance per direction - and that ssh1_cipher automatically initialised the IV to all zeroes, which ssh1bpp now has to do by hand.) The previous ssh1_cipher vtable for single-DES has been removed completely, because when converted into the new API it became identical to the SSH-2 single-DES vtable; so now there's just one vtable for DES-CBC which works in both protocols. The other two SSH-1 ciphers each had to stay separate, because 3DES is completely different between SSH-1 and SSH-2 (three layers of CBC structure versus one), and Blowfish varies in endianness and key length between the two. (Actually, while I'm here, I've only just noticed that the SSH-1 Blowfish cipher mis-describes itself in log messages as Blowfish-128. In fact it passes the whole of the input key buffer, which has length SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually Blowfish-256, and has been all along!)
2019-01-17 21:06:08 +03:00
const ssh_cipheralg *const *list;
Support for selecting AES from the GUI. In the process, I've had to introduce another layer of abstraction in SSH2 ciphers, such that a single `logical cipher' (as desired by a user) can equate to more than one `physical cipher'. This is because AES comes in several key lengths (PuTTY will pick the highest supported by the remote end) and several different SSH2-protocol-level names (aes*-cbc, rijndael*-cbc, and an unofficial one rijndael-cbc@lysator.liu.se). [originally from svn r967]
2001-03-02 16:55:23 +03: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 09:51:44 +03:00
struct ssh2_mac {
const ssh2_macalg *vt;
Turn SSH-2 MACs into a classoid. This piece of tidying-up has come out particularly well in terms of saving tedious repetition and boilerplate. I've managed to remove three pointless methods from every MAC implementation by means of writing them once centrally in terms of the implementation-specific methods; another method (hmacmd5_sink) vanished because I was able to make the interface type 'ssh2_mac' be directly usable as a BinarySink by way of a new delegation system; and because all the method implementations can now find their own vtable, I was even able to merge a lot of keying and output functions that had previously differed only in length parameters by having them look up the lengths in whatever vtable they were passed.
2018-09-13 18:15:17 +03:00
BinarySink_DELEGATE_IMPLEMENTATION;
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 09:51:44 +03:00
};
Turn SSH-2 MACs into a classoid. This piece of tidying-up has come out particularly well in terms of saving tedious repetition and boilerplate. I've managed to remove three pointless methods from every MAC implementation by means of writing them once centrally in terms of the implementation-specific methods; another method (hmacmd5_sink) vanished because I was able to make the interface type 'ssh2_mac' be directly usable as a BinarySink by way of a new delegation system; and because all the method implementations can now find their own vtable, I was even able to merge a lot of keying and output functions that had previously differed only in length parameters by having them look up the lengths in whatever vtable they were passed.
2018-09-13 18:15:17 +03:00
struct ssh2_macalg {
Allow a cipher to override the SSH KEX's choice of MAC. No cipher uses this facility yet, but one shortly will.
2015-06-07 15:40:11 +03:00
/* Passes in the cipher context */
Merge the ssh1_cipher type into ssh2_cipher. The aim of this reorganisation is to make it easier to test all the ciphers in PuTTY in a uniform way. It was inconvenient that there were two separate vtable systems for the ciphers used in SSH-1 and SSH-2 with different functionality. Now there's only one type, called ssh_cipher. But really it's the old ssh2_cipher, just renamed: I haven't made any changes to the API on the SSH-2 side. Instead, I've removed ssh1_cipher completely, and adapted the SSH-1 BPP to use the SSH-2 style API. (The relevant differences are that ssh1_cipher encapsulated both the sending and receiving directions in one object - so now ssh1bpp has to make a separate cipher instance per direction - and that ssh1_cipher automatically initialised the IV to all zeroes, which ssh1bpp now has to do by hand.) The previous ssh1_cipher vtable for single-DES has been removed completely, because when converted into the new API it became identical to the SSH-2 single-DES vtable; so now there's just one vtable for DES-CBC which works in both protocols. The other two SSH-1 ciphers each had to stay separate, because 3DES is completely different between SSH-1 and SSH-2 (three layers of CBC structure versus one), and Blowfish varies in endianness and key length between the two. (Actually, while I'm here, I've only just noticed that the SSH-1 Blowfish cipher mis-describes itself in log messages as Blowfish-128. In fact it passes the whole of the input key buffer, which has length SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually Blowfish-256, and has been all along!)
2019-01-17 21:06:08 +03:00
ssh2_mac *(*new)(const ssh2_macalg *alg, ssh_cipher *cipher);
Turn SSH-2 MACs into a classoid. This piece of tidying-up has come out particularly well in terms of saving tedious repetition and boilerplate. I've managed to remove three pointless methods from every MAC implementation by means of writing them once centrally in terms of the implementation-specific methods; another method (hmacmd5_sink) vanished because I was able to make the interface type 'ssh2_mac' be directly usable as a BinarySink by way of a new delegation system; and because all the method implementations can now find their own vtable, I was even able to merge a lot of keying and output functions that had previously differed only in length parameters by having them look up the lengths in whatever vtable they were passed.
2018-09-13 18:15:17 +03:00
void (*free)(ssh2_mac *);
Make ssh2_mac_setkey take the key as a ptrlen. This makes the API more flexible, so that it's not restricted to taking a key of precisely the length specified in the ssh2_macalg structure. Instead, ssh2bpp looks up that length to construct the MAC's key. Some MACs (e.g. Poly1305) will only _work_ with a single key length. But this way, I can run standard test vectors against MACs that can take a variable length (e.g. everything in the HMAC family).
2019-01-03 16:49:02 +03:00
void (*setkey)(ssh2_mac *, ptrlen key);
Turn SSH-2 MACs into a classoid. This piece of tidying-up has come out particularly well in terms of saving tedious repetition and boilerplate. I've managed to remove three pointless methods from every MAC implementation by means of writing them once centrally in terms of the implementation-specific methods; another method (hmacmd5_sink) vanished because I was able to make the interface type 'ssh2_mac' be directly usable as a BinarySink by way of a new delegation system; and because all the method implementations can now find their own vtable, I was even able to merge a lot of keying and output functions that had previously differed only in length parameters by having them look up the lengths in whatever vtable they were passed.
2018-09-13 18:15:17 +03:00
void (*start)(ssh2_mac *);
void (*genresult)(ssh2_mac *, unsigned char *);
Turn ssh2_mac's text_name field into a method. This allows a MAC implementation to construct its textual name at run time. Nothing yet uses that flexibility, though.
2019-01-20 14:32:26 +03:00
const char *(*text_name)(ssh2_mac *);
Const-correctness of name fields in struct ssh_*. All the name strings in ssh_cipher, ssh_mac, ssh_hash, ssh_signkey point to compile-time string literals, hence should obviously be const char *. Most of these const-correctness patches are just a mechanical job of adding a 'const' in the one place you need it right now, and then chasing the implications through the code adding further consts until it compiles. But this one has actually shown up a bug: the 'algorithm' output parameter in ssh2_userkey_loadpub was sometimes returning a pointer to a string literal, and sometimes a pointer to dynamically allocated memory, so callers were forced to either sometimes leak memory or sometimes free a bad thing. Now it's consistently dynamically allocated, and should be freed everywhere too.
2015-05-15 12:12:06 +03:00
const char *name, *etm_name;
Add a key-length field to 'struct ssh_mac'. The key derivation code has been assuming (though non-critically, as it happens) that the size of the MAC output is the same as the size of the MAC key. That isn't even a good assumption for the HMAC family, due to HMAC-SHA1-96 and also the bug-compatible versions of HMAC-SHA1 that only use 16 bytes of key material; so now we have an explicit key-length field separate from the MAC-length field.
2015-08-22 01:20:12 +03:00
int len, keylen;
Add an 'extra' pointer field to ssh2_macalg. Similar to the versions in ssh_cipheralg and ssh_keyalg, this allows a set of vtables to share function pointers while providing varying constant data that the shared function can use to vary its behaviour. As an initial demonstration, I've used this to recombine the four trivial text_name methods for the HMAC-SHA1 variants. I'm about to use it for something more sensible, though.
2019-01-20 14:37:05 +03:00
/* Pointer to any extra data used by a particular implementation. */
const void *extra;
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 18:28:17 +04:00
};
Replace method-dispatch #defines with inline functions. This replaces all the macros like ssh_key_sign() and win_draw_text() which take an object containing a vtable pointer and do the dereferencing to find the actual concrete method to call. Now they're all inline functions, which means more sensible type-checking and more comprehensible error reports when the types go wrong, and also means that there's no risk of double-evaluating the object argument.
2019-02-27 22:44:15 +03:00
static inline ssh2_mac *ssh2_mac_new(
const ssh2_macalg *alg, ssh_cipher *cipher)
{ return alg->new(alg, cipher); }
static inline void ssh2_mac_free(ssh2_mac *m)
{ m->vt->free(m); }
static inline void ssh2_mac_setkey(ssh2_mac *m, ptrlen key)
{ m->vt->setkey(m, key); }
static inline void ssh2_mac_start(ssh2_mac *m)
{ m->vt->start(m); }
static inline void ssh2_mac_genresult(ssh2_mac *m, unsigned char *out)
{ m->vt->genresult(m, out); }
static inline const char *ssh2_mac_text_name(ssh2_mac *m)
{ return m->vt->text_name(m); }
static inline const ssh2_macalg *ssh2_mac_alg(ssh2_mac *m)
{ return m->vt; }
Turn SSH-2 MACs into a classoid. This piece of tidying-up has come out particularly well in terms of saving tedious repetition and boilerplate. I've managed to remove three pointless methods from every MAC implementation by means of writing them once centrally in terms of the implementation-specific methods; another method (hmacmd5_sink) vanished because I was able to make the interface type 'ssh2_mac' be directly usable as a BinarySink by way of a new delegation system; and because all the method implementations can now find their own vtable, I was even able to merge a lot of keying and output functions that had previously differed only in length parameters by having them look up the lengths in whatever vtable they were passed.
2018-09-13 18:15:17 +03:00
Access all hashes and MACs through the standard API. All the hash-specific state structures, and the functions that directly accessed them, are now local to the source files implementing the hashes themselves. Everywhere we previously used those types or functions, we're now using the standard ssh_hash or ssh2_mac API. The 'simple' functions (hmacmd5_simple, SHA_Simple etc) are now a pair of wrappers in sshauxcrypt.c, each of which takes an algorithm structure and can do the same conceptual thing regardless of what it is.
2019-01-20 19:15:14 +03:00
/* Centralised 'methods' for ssh2_mac, defined in sshmac.c. These run
* the MAC in a specifically SSH-2 style, i.e. taking account of a
* packet sequence number as well as the data to be authenticated. */
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 22:23:19 +03:00
bool ssh2_mac_verresult(ssh2_mac *, const void *);
Turn SSH-2 MACs into a classoid. This piece of tidying-up has come out particularly well in terms of saving tedious repetition and boilerplate. I've managed to remove three pointless methods from every MAC implementation by means of writing them once centrally in terms of the implementation-specific methods; another method (hmacmd5_sink) vanished because I was able to make the interface type 'ssh2_mac' be directly usable as a BinarySink by way of a new delegation system; and because all the method implementations can now find their own vtable, I was even able to merge a lot of keying and output functions that had previously differed only in length parameters by having them look up the lengths in whatever vtable they were passed.
2018-09-13 18:15:17 +03:00
void ssh2_mac_generate(ssh2_mac *, void *, int, unsigned long seq);
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 22:23:19 +03:00
bool ssh2_mac_verify(ssh2_mac *, const void *, int, unsigned long seq);
Turn SSH-2 MACs into a classoid. This piece of tidying-up has come out particularly well in terms of saving tedious repetition and boilerplate. I've managed to remove three pointless methods from every MAC implementation by means of writing them once centrally in terms of the implementation-specific methods; another method (hmacmd5_sink) vanished because I was able to make the interface type 'ssh2_mac' be directly usable as a BinarySink by way of a new delegation system; and because all the method implementations can now find their own vtable, I was even able to merge a lot of keying and output functions that had previously differed only in length parameters by having them look up the lengths in whatever vtable they were passed.
2018-09-13 18:15:17 +03:00
Access all hashes and MACs through the standard API. All the hash-specific state structures, and the functions that directly accessed them, are now local to the source files implementing the hashes themselves. Everywhere we previously used those types or functions, we're now using the standard ssh_hash or ssh2_mac API. The 'simple' functions (hmacmd5_simple, SHA_Simple etc) are now a pair of wrappers in sshauxcrypt.c, each of which takes an algorithm structure and can do the same conceptual thing regardless of what it is.
2019-01-20 19:15:14 +03:00
/* Use a MAC in its raw form, outside SSH-2 context, to MAC a given
* string with a given key in the most obvious way. */
void mac_simple(const ssh2_macalg *alg, ptrlen key, ptrlen data, void *output);
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 09:51:44 +03:00
struct ssh_hash {
const ssh_hashalg *vt;
Turn SSH hashes into a classoid. The new version of ssh_hash has the same nice property as ssh2_mac, that I can make the generic interface object type function directly as a BinarySink so that clients don't have to call h->sink() and worry about the separate sink object they get back from that.
2018-09-13 18:41:46 +03:00
BinarySink_DELEGATE_IMPLEMENTATION;
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 09:51:44 +03:00
};
Turn SSH hashes into a classoid. The new version of ssh_hash has the same nice property as ssh2_mac, that I can make the generic interface object type function directly as a BinarySink so that clients don't have to call h->sink() and worry about the separate sink object they get back from that.
2018-09-13 18:41:46 +03: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 09:51:44 +03:00
struct ssh_hashalg {
ssh_hash *(*new)(const ssh_hashalg *alg);
Turn SSH hashes into a classoid. The new version of ssh_hash has the same nice property as ssh2_mac, that I can make the generic interface object type function directly as a BinarySink so that clients don't have to call h->sink() and worry about the separate sink object they get back from that.
2018-09-13 18:41:46 +03:00
ssh_hash *(*copy)(ssh_hash *);
void (*final)(ssh_hash *, unsigned char *); /* ALSO FREES THE ssh_hash! */
void (*free)(ssh_hash *);
Add infrastructure for supporting multiple hashes in key exchange. Nothing very surprising here. [originally from svn r6251]
2005-09-01 00:43:06 +04:00
int hlen; /* output length in bytes */
Expose blocklen in the ssh_hash structure. Keeping that information alongside the hashes themselves seems more sensible than having the HMAC code know that fact about everything it can work with.
2019-01-21 22:04:22 +03:00
int blocklen; /* length of the hash's input block, or 0 for N/A */
Identify hash function implementations in the Event Log. Similarly to the 'AES (unaccelerated)' naming scheme I added in the AES rewrite, the hash functions that have multiple implementations now each come with an annotation saying which one they are. This was more tricky for hashes than for ciphers, because the annotation for a hash has to be a separate string literal from the base text name, so that it can propagate into the name field for each HMAC wrapper without looking silly.
2019-01-23 10:29:53 +03:00
const char *text_basename; /* the semantic name of the hash */
const char *annotation; /* extra info, e.g. which of multiple impls */
const char *text_name; /* both combined, e.g. "SHA-n (unaccelerated)" */
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 09:51:44 +03:00
};
Add infrastructure for supporting multiple hashes in key exchange. Nothing very surprising here. [originally from svn r6251]
2005-09-01 00:43:06 +04:00
Replace method-dispatch #defines with inline functions. This replaces all the macros like ssh_key_sign() and win_draw_text() which take an object containing a vtable pointer and do the dereferencing to find the actual concrete method to call. Now they're all inline functions, which means more sensible type-checking and more comprehensible error reports when the types go wrong, and also means that there's no risk of double-evaluating the object argument.
2019-02-27 22:44:15 +03:00
static inline ssh_hash *ssh_hash_new(const ssh_hashalg *alg)
{ return alg->new(alg); }
static inline ssh_hash *ssh_hash_copy(ssh_hash *h)
{ return h->vt->copy(h); }
static inline void ssh_hash_final(ssh_hash *h, unsigned char *out)
{ return h->vt->final(h, out); }
static inline void ssh_hash_free(ssh_hash *h)
{ return h->vt->free(h); }
static inline const ssh_hashalg *ssh_hash_alg(ssh_hash *h)
{ return h->vt; }
Turn SSH hashes into a classoid. The new version of ssh_hash has the same nice property as ssh2_mac, that I can make the generic interface object type function directly as a BinarySink so that clients don't have to call h->sink() and worry about the separate sink object they get back from that.
2018-09-13 18:41:46 +03:00
Identify hash function implementations in the Event Log. Similarly to the 'AES (unaccelerated)' naming scheme I added in the AES rewrite, the hash functions that have multiple implementations now each come with an annotation saying which one they are. This was more tricky for hashes than for ciphers, because the annotation for a hash has to be a separate string literal from the base text name, so that it can propagate into the name field for each HMAC wrapper without looking silly.
2019-01-23 10:29:53 +03:00
/* Handy macros for defining all those text-name fields at once */
#define HASHALG_NAMES_BARE(base) \
base, NULL, base
#define HASHALG_NAMES_ANNOTATED(base, annotation) \
base, annotation, base " (" annotation ")"
Access all hashes and MACs through the standard API. All the hash-specific state structures, and the functions that directly accessed them, are now local to the source files implementing the hashes themselves. Everywhere we previously used those types or functions, we're now using the standard ssh_hash or ssh2_mac API. The 'simple' functions (hmacmd5_simple, SHA_Simple etc) are now a pair of wrappers in sshauxcrypt.c, each of which takes an algorithm structure and can do the same conceptual thing regardless of what it is.
2019-01-20 19:15:14 +03:00
void hash_simple(const ssh_hashalg *alg, ptrlen data, void *output);
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 18:28:17 +04:00
struct ssh_kex {
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 13:15:42 +03:00
const char *name, *groupname;
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 09:18:59 +03:00
enum { KEXTYPE_DH, KEXTYPE_RSA, KEXTYPE_ECDH, KEXTYPE_GSS } main_type;
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 09:51:44 +03:00
const ssh_hashalg *hash;
Provide an 'extra' pointer in ssh_signkey and ssh_kex. This gives families of public key and kex functions (by which I mean those sharing a set of methods) a place to store parameters that allow the methods to vary depending on which exact algorithm is in use. The ssh_kex structure already had a set of parameters specific to Diffie-Hellman key exchange; I've moved those into sshdh.c and made them part of the 'extra' structure for that family only, so that unrelated kex methods don't have to faff about saying NULL,NULL,0,0. (This required me to write an extra accessor function for ssh.c to ask whether a DH method was group-exchange style or fixed-group style, but that doesn't seem too silly.)
2015-05-15 12:12:08 +03:00
const void *extra; /* private to the kex methods */
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 18:28:17 +04:00
};
Restructure things so that a single entry in the KEX preference list can correspond to multiple SSH-2 KEX algorithms. We already do the equivalent for cipher algorithms. [originally from svn r6262]
2005-09-03 17:41:43 +04:00
struct ssh_kexes {
int nkexes;
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 09:51:44 +03:00
const ssh_kex *const *list;
Restructure things so that a single entry in the KEX preference list can correspond to multiple SSH-2 KEX algorithms. We already do the equivalent for cipher algorithms. [originally from svn r6262]
2005-09-03 17:41:43 +04:00
};
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
struct ssh_keyalg {
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
/* Constructors that create an ssh_key */
ssh_key *(*new_pub) (const ssh_keyalg *self, ptrlen pub);
ssh_key *(*new_priv) (const ssh_keyalg *self, ptrlen pub, ptrlen priv);
ssh_key *(*new_priv_openssh) (const ssh_keyalg *self, BinarySource *);
/* Methods that operate on an existing ssh_key */
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
void (*freekey) (ssh_key *key);
Give a sensible error when using a too-short RSA key. The ssh_signkey vtable has grown a new method ssh_key_invalid(), which checks whether the key is going to be usable for constructing a signature at all. Currently the only way this can fail is if it's an RSA key so short that there isn't room to put all the PKCS#1 formatting in the signature preimage integer, but the return value is an arbitrary error message just in case more reasons are needed later. This is tested separately rather than at key-creation time because of the signature flags system: an RSA key of intermediate length could be valid for SHA-1 signing but not for SHA-512. So really this method should be called at the point where you've decided what sig flags you want to use, and you're checking if _those flags_ are OK. On the verification side, there's no need for a separate check. If someone presents us with an RSA key so short that it's impossible to encode a valid signature using it, then we simply regard all signatures as invalid.
2019-02-10 11:44:59 +03:00
char *(*invalid) (ssh_key *key, unsigned flags);
Replace more (pointer, length) arg pairs with ptrlen. The abstract method ssh_key_sign(), and the concrete functions ssh_rsakex_newkey() and rsa_ssh1_public_blob_len(), now each take a ptrlen argument in place of a separate pointer and length pair. Partly that's because I'm generally preferring ptrlens these days and it keeps argument lists short and tidy-looking, but mostly it's because it will make those functions easier to wrap in my upcoming test system.
2019-01-02 00:07:48 +03:00
void (*sign) (ssh_key *key, ptrlen data, unsigned flags, BinarySink *);
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 22:23:19 +03:00
bool (*verify) (ssh_key *key, ptrlen sig, ptrlen data);
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
void (*public_blob)(ssh_key *key, BinarySink *);
void (*private_blob)(ssh_key *key, BinarySink *);
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
void (*openssh_blob) (ssh_key *key, BinarySink *);
char *(*cache_str) (ssh_key *key);
/* 'Class methods' that don't deal with an ssh_key at all */
Clean up ssh_keyalg APIs and implementations. Quite a few of the function pointers in the ssh_keyalg vtable now take ptrlen arguments in place of separate pointer and length pairs. Meanwhile, the various key types' implementations of those functions now work by initialising a BinarySource with the input ptrlen and using the new decode functions to walk along it. One exception is the openssh_createkey method which reads a private key in the wire format used by OpenSSH's SSH-2 agent protocol, which has to consume a prefix of a larger data stream, and tell the caller how much of that data was the private key. That function now takes an actual BinarySource, and passes that directly to the decode functions, so that on return the caller finds that the BinarySource's read pointer has been advanced exactly past the private key. This let me throw away _several_ reimplementations of mpint-reading functions, one in each of sshrsa, sshdss.c and sshecc.c. Worse still, they didn't all have exactly the SSH-2 semantics, because the thing in sshrsa.c whose name suggested it was an mpint-reading function actually tolerated the wrong number of leading zero bytes, which it had to be able to do to cope with the "ssh-rsa" signature format which contains a thing that isn't quite an SSH-2 mpint. Now that deviation is clearly commented!
2018-05-31 20:40:51 +03:00
int (*pubkey_bits) (const ssh_keyalg *self, ptrlen blob);
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
/* Constant data fields giving information about the key type */
const char *ssh_id; /* string identifier in the SSH protocol */
const char *cache_id; /* identifier used in PuTTY's host key cache */
const void *extra; /* private to the public key methods */
Pass flags from agent sign request to ssh_key_sign. Now each public-key algorithm gets to indicate what flags it supports, and the ones it specifies support for may turn up in a call to its sign() method. We still don't actually support any flags yet, though.
2018-11-19 23:24:37 +03:00
const unsigned supported_flags; /* signature-type flags we understand */
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 18:28:17 +04:00
};
Replace method-dispatch #defines with inline functions. This replaces all the macros like ssh_key_sign() and win_draw_text() which take an object containing a vtable pointer and do the dereferencing to find the actual concrete method to call. Now they're all inline functions, which means more sensible type-checking and more comprehensible error reports when the types go wrong, and also means that there's no risk of double-evaluating the object argument.
2019-02-27 22:44:15 +03:00
static inline ssh_key *ssh_key_new_pub(const ssh_keyalg *self, ptrlen pub)
{ return self->new_pub(self, pub); }
static inline ssh_key *ssh_key_new_priv(
const ssh_keyalg *self, ptrlen pub, ptrlen priv)
{ return self->new_priv(self, pub, priv); }
static inline ssh_key *ssh_key_new_priv_openssh(
const ssh_keyalg *self, BinarySource *src)
{ return self->new_priv_openssh(self, src); }
static inline void ssh_key_free(ssh_key *key)
{ key->vt->freekey(key); }
static inline char *ssh_key_invalid(ssh_key *key, unsigned flags)
{ return key->vt->invalid(key, flags); }
static inline void ssh_key_sign(
ssh_key *key, ptrlen data, unsigned flags, BinarySink *bs)
{ key->vt->sign(key, data, flags, bs); }
static inline bool ssh_key_verify(ssh_key *key, ptrlen sig, ptrlen data)
{ return key->vt->verify(key, sig, data); }
static inline void ssh_key_public_blob(ssh_key *key, BinarySink *bs)
{ key->vt->public_blob(key, bs); }
static inline void ssh_key_private_blob(ssh_key *key, BinarySink *bs)
{ key->vt->private_blob(key, bs); }
static inline void ssh_key_openssh_blob(ssh_key *key, BinarySink *bs)
{ key->vt->openssh_blob(key, bs); }
static inline char *ssh_key_cache_str(ssh_key *key)
{ return key->vt->cache_str(key); }
static inline int ssh_key_public_bits(const ssh_keyalg *self, ptrlen blob)
{ return self->pubkey_bits(self, blob); }
static inline const ssh_keyalg *ssh_key_alg(ssh_key *key)
{ return key->vt; }
static inline const char *ssh_key_ssh_id(ssh_key *key)
{ return key->vt->ssh_id; }
static inline const char *ssh_key_cache_id(ssh_key *key)
{ return key->vt->cache_id; }
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
Support SHA-256 and SHA-512 based RSA signatures. Now the RSA signing function supports the two flags defined in draft-miller-ssh-agent-02, and uses them to generate RSA signatures based on SHA-256 and SHA-512, which look exactly like the ordinary kind of RSA SHA-1 signature except that the decoded signature integer has a different hash at the bottom and an ASN.1 identifying prefix to match, and also the signature-type string prefixing the integer changes from "ssh-rsa" to "rsa-sha2-256" or "rsa-sha2-512" as appropriate. We don't _accept_ signatures of these new types - that would need an entirely different protocol extension - and we don't generate them under any circumstances other than Pageant receiving a sign request with one of those flags set.
2018-11-19 23:46:59 +03:00
/*
* Enumeration of signature flags from draft-miller-ssh-agent-02
*/
#define SSH_AGENT_RSA_SHA2_256 2
#define SSH_AGENT_RSA_SHA2_512 4
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 09:51:44 +03:00
struct ssh_compressor {
const ssh_compression_alg *vt;
};
struct ssh_decompressor {
const ssh_compression_alg *vt;
};
Make ssh_compress into a pair of linked classoids. This was mildly fiddly because there's a single vtable structure that implements two distinct interface types, one for compression and one for decompression - and I have actually confused them before now (commit d4304f1b7), so I think it's important to make them actually be separate types!
2018-09-14 11:16:41 +03:00
struct ssh_compression_alg {
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 13:15:42 +03:00
const char *name;
Implement zlib@openssh.com, using the rekey-after-userauth method suggested in the wishlist entry. [originally from svn r9120] [this svn revision also touched putty-website,putty-wishlist]
2011-03-05 01:34:47 +03:00
/* For zlib@openssh.com: if non-NULL, this name will be considered once
* userauth has completed successfully. */
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 13:15:42 +03:00
const char *delayed_name;
Make ssh_compress into a pair of linked classoids. This was mildly fiddly because there's a single vtable structure that implements two distinct interface types, one for compression and one for decompression - and I have actually confused them before now (commit d4304f1b7), so I think it's important to make them actually be separate types!
2018-09-14 11:16:41 +03:00
ssh_compressor *(*compress_new)(void);
void (*compress_free)(ssh_compressor *);
Add some missing 'const' in the compressor API.
2018-11-27 22:22:02 +03:00
void (*compress)(ssh_compressor *, const unsigned char *block, int len,
Make ssh_compress into a pair of linked classoids. This was mildly fiddly because there's a single vtable structure that implements two distinct interface types, one for compression and one for decompression - and I have actually confused them before now (commit d4304f1b7), so I think it's important to make them actually be separate types!
2018-09-14 11:16:41 +03:00
unsigned char **outblock, int *outlen,
int minlen);
ssh_decompressor *(*decompress_new)(void);
void (*decompress_free)(ssh_decompressor *);
Add some missing 'const' in the compressor API.
2018-11-27 22:22:02 +03:00
bool (*decompress)(ssh_decompressor *, const unsigned char *block, int len,
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 22:23:19 +03:00
unsigned char **outblock, int *outlen);
Const-correctness of name fields in struct ssh_*. All the name strings in ssh_cipher, ssh_mac, ssh_hash, ssh_signkey point to compile-time string literals, hence should obviously be const char *. Most of these const-correctness patches are just a mechanical job of adding a 'const' in the one place you need it right now, and then chasing the implications through the code adding further consts until it compiles. But this one has actually shown up a bug: the 'algorithm' output parameter in ssh2_userkey_loadpub was sometimes returning a pointer to a string literal, and sometimes a pointer to dynamically allocated memory, so callers were forced to either sometimes leak memory or sometimes free a bad thing. Now it's consistently dynamically allocated, and should be freed everywhere too.
2015-05-15 12:12:06 +03:00
const char *text_name;
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 16:02:13 +03:00
};
Replace method-dispatch #defines with inline functions. This replaces all the macros like ssh_key_sign() and win_draw_text() which take an object containing a vtable pointer and do the dereferencing to find the actual concrete method to call. Now they're all inline functions, which means more sensible type-checking and more comprehensible error reports when the types go wrong, and also means that there's no risk of double-evaluating the object argument.
2019-02-27 22:44:15 +03:00
static inline ssh_compressor *ssh_compressor_new(
const ssh_compression_alg *alg)
{ return alg->compress_new(); }
static inline ssh_decompressor *ssh_decompressor_new(
const ssh_compression_alg *alg)
{ return alg->decompress_new(); }
static inline void ssh_compressor_free(ssh_compressor *c)
{ c->vt->compress_free(c); }
static inline void ssh_decompressor_free(ssh_decompressor *d)
{ d->vt->decompress_free(d); }
static inline void ssh_compressor_compress(
ssh_compressor *c, const unsigned char *block, int len,
unsigned char **outblock, int *outlen, int minlen)
{ c->vt->compress(c, block, len, outblock, outlen, minlen); }
static inline bool ssh_decompressor_decompress(
ssh_decompressor *d, const unsigned char *block, int len,
unsigned char **outblock, int *outlen)
{ return d->vt->decompress(d, block, len, outblock, outlen); }
static inline const ssh_compression_alg *ssh_compressor_alg(
ssh_compressor *c)
{ return c->vt; }
static inline const ssh_compression_alg *ssh_decompressor_alg(
ssh_decompressor *d)
{ return d->vt; }
Make ssh_compress into a pair of linked classoids. This was mildly fiddly because there's a single vtable structure that implements two distinct interface types, one for compression and one for decompression - and I have actually confused them before now (commit d4304f1b7), so I think it's important to make them actually be separate types!
2018-09-14 11:16:41 +03:00
Preliminary support for RSA user authentication in SSH2! Most of the error messages are currently wrong, and Pageant doesn't yet support the new key type, and I haven't thoroughly tested that falling back to password authentication and trying invalid keys etc all work. But what I have here has successfully performed a public key authentication, so it's working to at least some extent. [originally from svn r973]
2001-03-03 14:54:34 +03:00
struct ssh2_userkey {
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
ssh_key *key; /* the key itself */
Preliminary support for RSA user authentication in SSH2! Most of the error messages are currently wrong, and Pageant doesn't yet support the new key type, and I haven't thoroughly tested that falling back to password authentication and trying invalid keys etc all work. But what I have here has successfully performed a public key authentication, so it's working to at least some extent. [originally from svn r973]
2001-03-03 14:54:34 +03:00
char *comment; /* the key comment */
};
Rename SSH2_KEX_MAX_HASH_LEN to be more general. I'm about to want to use it for purposes other than KEX, so it's now just called MAX_HASH_LEN and is supposed to be an upper bound on any hash function we implement at all. Of course this makes no difference to its value, because the largest hash we have is SHA-512 which already fit inside that limit.
2019-01-03 01:00:23 +03:00
/* The maximum length of any hash algorithm. (bytes) */
#define MAX_HASH_LEN (64) /* longest is SHA-512 */
Dimitry Andric spotted that DH gex with SHA-256 was overflowing a buffer. Fixed, and added paranoia so that this shouldn't happen again. [originally from svn r6606] [this svn revision also touched putty-wishlist]
2006-03-12 22:24:05 +03:00
Merge the ssh1_cipher type into ssh2_cipher. The aim of this reorganisation is to make it easier to test all the ciphers in PuTTY in a uniform way. It was inconvenient that there were two separate vtable systems for the ciphers used in SSH-1 and SSH-2 with different functionality. Now there's only one type, called ssh_cipher. But really it's the old ssh2_cipher, just renamed: I haven't made any changes to the API on the SSH-2 side. Instead, I've removed ssh1_cipher completely, and adapted the SSH-1 BPP to use the SSH-2 style API. (The relevant differences are that ssh1_cipher encapsulated both the sending and receiving directions in one object - so now ssh1bpp has to make a separate cipher instance per direction - and that ssh1_cipher automatically initialised the IV to all zeroes, which ssh1bpp now has to do by hand.) The previous ssh1_cipher vtable for single-DES has been removed completely, because when converted into the new API it became identical to the SSH-2 single-DES vtable; so now there's just one vtable for DES-CBC which works in both protocols. The other two SSH-1 ciphers each had to stay separate, because 3DES is completely different between SSH-1 and SSH-2 (three layers of CBC structure versus one), and Blowfish varies in endianness and key length between the two. (Actually, while I'm here, I've only just noticed that the SSH-1 Blowfish cipher mis-describes itself in log messages as Blowfish-128. In fact it passes the whole of the input key buffer, which has length SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually Blowfish-256, and has been all along!)
2019-01-17 21:06:08 +03:00
extern const ssh_cipheralg ssh_3des_ssh1;
extern const ssh_cipheralg ssh_blowfish_ssh1;
extern const ssh_cipheralg ssh_3des_ssh2_ctr;
extern const ssh_cipheralg ssh_3des_ssh2;
extern const ssh_cipheralg ssh_des;
extern const ssh_cipheralg ssh_des_sshcom_ssh2;
extern const ssh_cipheralg ssh_aes256_sdctr;
extern const ssh_cipheralg ssh_aes256_sdctr_hw;
extern const ssh_cipheralg ssh_aes256_sdctr_sw;
extern const ssh_cipheralg ssh_aes256_cbc;
extern const ssh_cipheralg ssh_aes256_cbc_hw;
extern const ssh_cipheralg ssh_aes256_cbc_sw;
extern const ssh_cipheralg ssh_aes192_sdctr;
extern const ssh_cipheralg ssh_aes192_sdctr_hw;
extern const ssh_cipheralg ssh_aes192_sdctr_sw;
extern const ssh_cipheralg ssh_aes192_cbc;
extern const ssh_cipheralg ssh_aes192_cbc_hw;
extern const ssh_cipheralg ssh_aes192_cbc_sw;
extern const ssh_cipheralg ssh_aes128_sdctr;
extern const ssh_cipheralg ssh_aes128_sdctr_hw;
extern const ssh_cipheralg ssh_aes128_sdctr_sw;
extern const ssh_cipheralg ssh_aes128_cbc;
extern const ssh_cipheralg ssh_aes128_cbc_hw;
extern const ssh_cipheralg ssh_aes128_cbc_sw;
extern const ssh_cipheralg ssh_blowfish_ssh2_ctr;
extern const ssh_cipheralg ssh_blowfish_ssh2;
extern const ssh_cipheralg ssh_arcfour256_ssh2;
extern const ssh_cipheralg ssh_arcfour128_ssh2;
extern const ssh_cipheralg ssh2_chacha20_poly1305;
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 09:51:44 +03:00
extern const ssh2_ciphers ssh2_3des;
extern const ssh2_ciphers ssh2_des;
extern const ssh2_ciphers ssh2_aes;
extern const ssh2_ciphers ssh2_blowfish;
extern const ssh2_ciphers ssh2_arcfour;
extern const ssh2_ciphers ssh2_ccp;
extern const ssh_hashalg ssh_md5;
extern const ssh_hashalg ssh_sha1;
Rewrite the SHA-256 and SHA-1 hash function modules. The new structure of those modules is along similar lines to the recent rewrite of AES, with selection of HW vs SW implementation being done by the main vtable instead of a subsidiary function pointer within it, freedom for each implementation to define its state structure however is most convenient, and space to drop in other hardware-accelerated implementations. I've removed the centralised test for compiler SHA-NI support in ssh.h, and instead duplicated it between the two SHA modules, on the grounds that once you start considering an open-ended set of hardware accelerators, the two hashes _need_ not go together. I've also added an extra test in cryptsuite that checks the point at which the end-of-hash padding switches to adding an extra cipher block. That was just because I was rewriting that padding code, was briefly worried that I might have got an off-by-one error in that part of it, and couldn't see any existing test that gave me confidence I hadn't.
2019-01-20 21:44:26 +03:00
extern const ssh_hashalg ssh_sha1_hw;
extern const ssh_hashalg ssh_sha1_sw;
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 09:51:44 +03:00
extern const ssh_hashalg ssh_sha256;
Rewrite the SHA-256 and SHA-1 hash function modules. The new structure of those modules is along similar lines to the recent rewrite of AES, with selection of HW vs SW implementation being done by the main vtable instead of a subsidiary function pointer within it, freedom for each implementation to define its state structure however is most convenient, and space to drop in other hardware-accelerated implementations. I've removed the centralised test for compiler SHA-NI support in ssh.h, and instead duplicated it between the two SHA modules, on the grounds that once you start considering an open-ended set of hardware accelerators, the two hashes _need_ not go together. I've also added an extra test in cryptsuite that checks the point at which the end-of-hash padding switches to adding an extra cipher block. That was just because I was rewriting that padding code, was briefly worried that I might have got an off-by-one error in that part of it, and couldn't see any existing test that gave me confidence I hadn't.
2019-01-20 21:44:26 +03:00
extern const ssh_hashalg ssh_sha256_hw;
extern const ssh_hashalg ssh_sha256_sw;
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 09:51:44 +03:00
extern const ssh_hashalg ssh_sha384;
extern const ssh_hashalg ssh_sha512;
extern const ssh_kexes ssh_diffiehellman_group1;
extern const ssh_kexes ssh_diffiehellman_group14;
extern const ssh_kexes ssh_diffiehellman_gex;
extern const ssh_kexes ssh_gssk5_sha1_kex;
extern const ssh_kexes ssh_rsa_kex;
extern const ssh_kex ssh_ec_kex_curve25519;
extern const ssh_kex ssh_ec_kex_nistp256;
extern const ssh_kex ssh_ec_kex_nistp384;
extern const ssh_kex ssh_ec_kex_nistp521;
extern const ssh_kexes ssh_ecdh_kex;
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
extern const ssh_keyalg ssh_dss;
extern const ssh_keyalg ssh_rsa;
extern const ssh_keyalg ssh_ecdsa_ed25519;
extern const ssh_keyalg ssh_ecdsa_nistp256;
extern const ssh_keyalg ssh_ecdsa_nistp384;
extern const ssh_keyalg ssh_ecdsa_nistp521;
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 09:51:44 +03:00
extern const ssh2_macalg ssh_hmac_md5;
extern const ssh2_macalg ssh_hmac_sha1;
extern const ssh2_macalg ssh_hmac_sha1_buggy;
extern const ssh2_macalg ssh_hmac_sha1_96;
extern const ssh2_macalg ssh_hmac_sha1_96_buggy;
extern const ssh2_macalg ssh_hmac_sha256;
extern const ssh2_macalg ssh2_poly1305;
extern const ssh_compression_alg ssh_zlib;
Rename ssh_md5 and ssh_sha1 to ssh_hmac_md5 and ssh_hmac_sha1 respectively. This is to make room for a hash abstraction that's likely to want to use ssh_sha1, at least. [originally from svn r6249]
2005-08-31 23:11:19 +04:00
Support hardware AES on Arm platforms. The refactored sshaes.c gives me a convenient slot to drop in a second hardware-accelerated AES implementation, similar to the existing one but using Arm NEON intrinsics in place of the x86 AES-NI ones. This needed a minor structural change, because Arm systems are often heterogeneous, containing more than one type of CPU which won't necessarily all support the same set of architecture features. So you can't test at run time for the presence of AES acceleration by querying the CPU you're running on - even if you found a way to do it, the answer wouldn't be reliable once the OS started migrating your process between CPUs. Instead, you have to ask the OS itself, because only that knows about _all_ the CPUs on the system. So that means the aes_hw_available() mechanism has to extend a tentacle into each platform subdirectory. The trickiest part was the nest of ifdefs that tries to detect whether the compiler can support the necessary parts. I had successful test-compiles on several compilers, and was able to run the code directly on an AArch64 tablet (so I know it passes cryptsuite), but it's likely that at least some Arm platforms won't be able to build it because of some path through the ifdefs that I haven't been able to test yet.
2019-01-17 01:08:45 +03:00
/*
* On some systems, you have to detect hardware crypto acceleration by
* asking the local OS API rather than OS-agnostically asking the CPU
* itself. If so, then this function should be implemented in each
* platform subdirectory.
*/
bool platform_aes_hw_available(void);
Support hardware SHA-256 and SHA-1 on Arm platforms. Similarly to my recent addition of NEON-accelerated AES, these new implementations drop in alongside the SHA-NI ones, under a different set of ifdefs. All the details of selection and detection are essentially the same as they were for the AES code.
2019-01-23 10:27:12 +03:00
bool platform_sha256_hw_available(void);
bool platform_sha1_hw_available(void);
Support hardware AES on Arm platforms. The refactored sshaes.c gives me a convenient slot to drop in a second hardware-accelerated AES implementation, similar to the existing one but using Arm NEON intrinsics in place of the x86 AES-NI ones. This needed a minor structural change, because Arm systems are often heterogeneous, containing more than one type of CPU which won't necessarily all support the same set of architecture features. So you can't test at run time for the presence of AES acceleration by querying the CPU you're running on - even if you found a way to do it, the answer wouldn't be reliable once the OS started migrating your process between CPUs. Instead, you have to ask the OS itself, because only that knows about _all_ the CPUs on the system. So that means the aes_hw_available() mechanism has to extend a tentacle into each platform subdirectory. The trickiest part was the nest of ifdefs that tries to detect whether the compiler can support the necessary parts. I had successful test-compiles on several compilers, and was able to run the code directly on an AArch64 tablet (so I know it passes cryptsuite), but it's likely that at least some Arm platforms won't be able to build it because of some path through the ifdefs that I haven't been able to test yet.
2019-01-17 01:08:45 +03:00
At long last: PuTTY will now report its version to the server sensibly, as a release or a snapshot or a local build. With any luck this should make bug reporting easier to handle, because anyone who sends their Event Log should automatically include the version :-) [originally from svn r1003]
2001-03-15 15:15:02 +03:00
/*
* PuTTY version number formatted as an SSH version string.
*/
Add some missing 'const' in version.c's string data. I can't believe this codebase is around 20 years old and has had multiple giant const-fixing patches, and yet there are _still_ things that should have been const for years and aren't.
2016-04-07 09:52:55 +03:00
extern const char sshver[];
At long last: PuTTY will now report its version to the server sensibly, as a release or a snapshot or a local build. With any luck this should make bug reporting easier to handle, because anyone who sends their Event Log should automatically include the version :-) [originally from svn r1003]
2001-03-15 15:15:02 +03:00
PSCP now uses the modern SFTP protocol if it can, and falls back to scp1 if it can't. Currently not very tested - I checked it in as soon as it completed a successful recursive copy in both directions. Also, one known bug: you can't specify a remote wildcard, because by the nature of SFTP we'll need to implement the wildcard engine on the client side. I do intend to do this (and use the same wildcard engine in PSFTP as well) but I haven't got round to it yet. [originally from svn r1208]
2001-08-26 22:32:28 +04:00
/*
* Gross hack: pscp will try to start SFTP but fall back to scp1 if
* that fails. This variable is the means by which scp.c can reach
* into the SSH code and find out which one it 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 22:23:19 +03:00
extern bool ssh_fallback_cmd(Backend *backend);
PSCP now uses the modern SFTP protocol if it can, and falls back to scp1 if it can't. Currently not very tested - I checked it in as soon as it completed a successful recursive copy in both directions. Also, one known bug: you can't specify a remote wildcard, because by the nature of SFTP we'll need to implement the wildcard engine on the client side. I do intend to do this (and use the same wildcard engine in PSFTP as well) but I haven't got round to it yet. [originally from svn r1208]
2001-08-26 22:32:28 +04:00
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-23 01:42:41 +03:00
/*
* The PRNG type, defined in sshprng.c. Visible data fields are
* 'savesize', which suggests how many random bytes you should request
* from a particular PRNG instance to write to putty.rnd, and a
* BinarySink implementation which you can use to write seed data in
* between calling prng_seed_{begin,finish}.
*/
struct prng {
size_t savesize;
BinarySink_IMPLEMENTATION;
/* (also there's a surrounding implementation struct in sshprng.c) */
};
prng *prng_new(const ssh_hashalg *hashalg);
void prng_free(prng *p);
void prng_seed_begin(prng *p);
void prng_seed_finish(prng *p);
void prng_read(prng *p, void *vout, size_t size);
void prng_add_entropy(prng *p, unsigned source_id, ptrlen data);
Windows PuTTYgen: bound entropy input by PRNG state size. Although I've reinstated the tedious manual mouse input, I can at least reduce the amount of it that the user is required to provide: the new PRNG has a hard limit on the size of its seed, so once we've generated enough entropy to fill that up, there's no point in collecting more, even if we're generating a particularly large key.
2019-02-10 16:43:14 +03:00
size_t prng_seed_bits(prng *p);
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-23 01:42:41 +03:00
/* This function must be implemented by the platform, and returns a
* timer in milliseconds that the PRNG can use to know whether it's
* been reseeded too recently to do it again.
*
* The PRNG system has its own special timing function not because its
* timing needs are unusual in the real applications, but simply so
* that testcrypt can mock it to keep the tests deterministic. */
uint64_t prng_reseed_time_ms(void);
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 22:43:27 +03:00
void random_read(void *out, size_t size);
Changes from executor: - NetHack keypad mode (Shift only works with NumLock off) - Alt-Space handling (best I could manage; not too bad considering) - Event Log rather than Telnet Negotiation Log [originally from svn r284]
1999-11-09 14:10:04 +03:00
Move x11fwd and portfwd prototypes from ssh.c into ssh.h so they can be seen by (and checked against) the definitions. [originally from svn r2474]
2003-01-06 01:53:23 +03:00
/* Exports from x11fwd.c */
Revamp of the local X11 connection code. We now parse X display strings more rigorously, and then we look up the local X authority data in .Xauthority _ourself_ rather than delegating to an external xauth program. This is (negligibly) more efficient on Unix, assuming I haven't got it wrong in some subtle way, but its major benefit is that we can now support X authority lookups on Windows as well provided the user points us at an appropriate X authority file in the standard format. A new Windows-specific config option has been added for this purpose. [originally from svn r8305]
2008-11-17 21:38:09 +03:00
enum {
X11_TRANS_IPV4 = 0, X11_TRANS_IPV6 = 6, X11_TRANS_UNIX = 256
};
struct X11Display {
/* Broken-down components of the display name itself */
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 22:23:19 +03:00
bool unixdomain;
Revamp of the local X11 connection code. We now parse X display strings more rigorously, and then we look up the local X authority data in .Xauthority _ourself_ rather than delegating to an external xauth program. This is (negligibly) more efficient on Unix, assuming I haven't got it wrong in some subtle way, but its major benefit is that we can now support X authority lookups on Windows as well provided the user points us at an appropriate X authority file in the standard format. A new Windows-specific config option has been added for this purpose. [originally from svn r8305]
2008-11-17 21:38:09 +03:00
char *hostname;
int displaynum;
int screennum;
/* OSX sometimes replaces all the above with a full Unix-socket pathname */
char *unixsocketpath;
/* PuTTY networking SockAddr to connect to the display, and associated
* gubbins */
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 21:10:23 +03:00
SockAddr *addr;
Revamp of the local X11 connection code. We now parse X display strings more rigorously, and then we look up the local X authority data in .Xauthority _ourself_ rather than delegating to an external xauth program. This is (negligibly) more efficient on Unix, assuming I haven't got it wrong in some subtle way, but its major benefit is that we can now support X authority lookups on Windows as well provided the user points us at an appropriate X authority file in the standard format. A new Windows-specific config option has been added for this purpose. [originally from svn r8305]
2008-11-17 21:38:09 +03:00
int port;
char *realhost;
/* Our local auth details for talking to the real X display. */
int localauthproto;
unsigned char *localauthdata;
int localauthdatalen;
Prepare to have multiple X11 auth cookies valid at once. Rather than the top-level component of X forwarding being an X11Display structure which owns some auth data, it's now a collection of X11FakeAuth structures, each of which owns a display. The idea is that when we receive an X connection, we wait to see which of our available auth cookies it matches, and then connect to whatever X display that auth cookie identifies. At present the tree will only have one thing in it; this is all groundwork for later changes. [originally from svn r10079]
2013-11-17 18:05:10 +04:00
};
struct X11FakeAuth {
/* Auth details we invented for a virtual display on the SSH server. */
int proto;
unsigned char *data;
int datalen;
char *protoname;
char *datastring;
/* The encrypted form of the first block, in XDM-AUTHORIZATION-1.
* Used as part of the key when these structures are organised
* into a tree. See x11_invent_fake_auth for explanation. */
unsigned char *xa1_firstblock;
Revamp of the local X11 connection code. We now parse X display strings more rigorously, and then we look up the local X authority data in .Xauthority _ourself_ rather than delegating to an external xauth program. This is (negligibly) more efficient on Unix, assuming I haven't got it wrong in some subtle way, but its major benefit is that we can now support X authority lookups on Windows as well provided the user points us at an appropriate X authority file in the standard format. A new Windows-specific config option has been added for this purpose. [originally from svn r8305]
2008-11-17 21:38:09 +03:00
/*
* Used inside x11fwd.c to remember recently seen
* XDM-AUTHORIZATION-1 strings, to avoid replay attacks.
*/
tree234 *xdmseen;
Prepare to have multiple X11 auth cookies valid at once. Rather than the top-level component of X forwarding being an X11Display structure which owns some auth data, it's now a collection of X11FakeAuth structures, each of which owns a display. The idea is that when we receive an X connection, we wait to see which of our available auth cookies it matches, and then connect to whatever X display that auth cookie identifies. At present the tree will only have one thing in it; this is all groundwork for later changes. [originally from svn r10079]
2013-11-17 18:05:10 +04:00
/*
* What to do with an X connection matching this auth data.
*/
struct X11Display *disp;
Expose structure tags for the connection-sharing data types. This was a particularly confusing piece of type-danger, because three different types were passed outside sshshare.c as 'void *' and only human vigilance prevented one coming back as the wrong one. Now they all keep their opaque structure tags when they move through other parts of the code.
2018-09-13 11:09:10 +03:00
ssh_sharing_connstate *share_cs;
share_channel *share_chan;
Revamp of the local X11 connection code. We now parse X display strings more rigorously, and then we look up the local X authority data in .Xauthority _ourself_ rather than delegating to an external xauth program. This is (negligibly) more efficient on Unix, assuming I haven't got it wrong in some subtle way, but its major benefit is that we can now support X authority lookups on Windows as well provided the user points us at an appropriate X authority file in the standard format. A new Windows-specific config option has been added for this purpose. [originally from svn r8305]
2008-11-17 21:38:09 +03:00
};
Refactor the construction of X protocol greetings. I've moved it out into a separate function, preparatory to calling it from somewhere completely different in changes to come. Also, we now retain the peer address sent from the SSH server in string form, rather than translating it immediately into a numeric IP address, so that its original form will be available later to pass on elsewhere. [originally from svn r10080]
2013-11-17 18:05:17 +04:00
void *x11_make_greeting(int endian, int protomajor, int protominor,
int auth_proto, const void *auth_data, int auth_len,
const char *peer_ip, int peer_port,
int *outlen);
Prepare to have multiple X11 auth cookies valid at once. Rather than the top-level component of X forwarding being an X11Display structure which owns some auth data, it's now a collection of X11FakeAuth structures, each of which owns a display. The idea is that when we receive an X connection, we wait to see which of our available auth cookies it matches, and then connect to whatever X display that auth cookie identifies. At present the tree will only have one thing in it; this is all groundwork for later changes. [originally from svn r10079]
2013-11-17 18:05:10 +04:00
int x11_authcmp(void *av, void *bv); /* for putting X11FakeAuth in a tree234 */
Revamp of the local X11 connection code. We now parse X display strings more rigorously, and then we look up the local X authority data in .Xauthority _ourself_ rather than delegating to an external xauth program. This is (negligibly) more efficient on Unix, assuming I haven't got it wrong in some subtle way, but its major benefit is that we can now support X authority lookups on Windows as well provided the user points us at an appropriate X authority file in the standard format. A new Windows-specific config option has been added for this purpose. [originally from svn r8305]
2008-11-17 21:38:09 +03:00
/*
* x11_setup_display() parses the display variable and fills in an
* X11Display structure. Some remote auth details are invented;
* the supplied authtype parameter configures the preferred
* authorisation protocol to use at the remote end. The local auth
* details are looked up by calling platform_get_x11_auth.
Return an error message from x11_setup_display. The lack of one of those has been a long-standing FIXME for ages.
2018-10-06 12:43:04 +03:00
*
* If the returned pointer is NULL, then *error_msg will contain a
* dynamically allocated error message string.
Revamp of the local X11 connection code. We now parse X display strings more rigorously, and then we look up the local X authority data in .Xauthority _ourself_ rather than delegating to an external xauth program. This is (negligibly) more efficient on Unix, assuming I haven't got it wrong in some subtle way, but its major benefit is that we can now support X authority lookups on Windows as well provided the user points us at an appropriate X authority file in the standard format. A new Windows-specific config option has been added for this purpose. [originally from svn r8305]
2008-11-17 21:38:09 +03:00
*/
Return an error message from x11_setup_display. The lack of one of those has been a long-standing FIXME for ages.
2018-10-06 12:43:04 +03:00
extern struct X11Display *x11_setup_display(const char *display, Conf *,
char **error_msg);
Revamp of the local X11 connection code. We now parse X display strings more rigorously, and then we look up the local X authority data in .Xauthority _ourself_ rather than delegating to an external xauth program. This is (negligibly) more efficient on Unix, assuming I haven't got it wrong in some subtle way, but its major benefit is that we can now support X authority lookups on Windows as well provided the user points us at an appropriate X authority file in the standard format. A new Windows-specific config option has been added for this purpose. [originally from svn r8305]
2008-11-17 21:38:09 +03:00
void x11_free_display(struct X11Display *disp);
Prepare to have multiple X11 auth cookies valid at once. Rather than the top-level component of X forwarding being an X11Display structure which owns some auth data, it's now a collection of X11FakeAuth structures, each of which owns a display. The idea is that when we receive an X connection, we wait to see which of our available auth cookies it matches, and then connect to whatever X display that auth cookie identifies. At present the tree will only have one thing in it; this is all groundwork for later changes. [originally from svn r10079]
2013-11-17 18:05:10 +04:00
struct X11FakeAuth *x11_invent_fake_auth(tree234 *t, int authtype);
void x11_free_fake_auth(struct X11FakeAuth *auth);
Put a layer of abstraction in front of struct ssh_channel. Clients outside ssh.c - all implementations of Channel - will now not see the ssh_channel data type itself, but only a subobject of the interface type SshChannel. All the sshfwd_* functions have become methods in that interface type's vtable (though, wrapped in the usual kind of macros, the call sites look identical). This paves the way for me to split up the SSH-1 and SSH-2 connection layers and have each one lay out its channel bookkeeping structure as it sees fit; as long as they each provide an implementation of the sshfwd_ method family, the types behind that need not look different. A minor good effect of this is that the sshfwd_ methods are no longer global symbols, so they don't have to be stubbed in Unix Pageant to get it to compile.
2018-09-14 15:47:13 +03:00
Channel *x11_new_channel(tree234 *authtree, SshChannel *c,
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03:00
const char *peeraddr, int peerport,
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 22:23:19 +03:00
bool connection_sharing_possible);
RJK's patch to enable PuTTY's X forwarding to connect to local X servers using Unix sockets (on Unix only, obviously!). [originally from svn r4263]
2004-05-31 18:01:52 +04:00
char *x11_display(const char *display);
/* Platform-dependent X11 functions */
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 22:52:21 +04:00
extern void platform_get_x11_auth(struct X11Display *display, Conf *);
Revamp of the local X11 connection code. We now parse X display strings more rigorously, and then we look up the local X authority data in .Xauthority _ourself_ rather than delegating to an external xauth program. This is (negligibly) more efficient on Unix, assuming I haven't got it wrong in some subtle way, but its major benefit is that we can now support X authority lookups on Windows as well provided the user points us at an appropriate X authority file in the standard format. A new Windows-specific config option has been added for this purpose. [originally from svn r8305]
2008-11-17 21:38:09 +03:00
/* examine a mostly-filled-in X11Display and fill in localauth* */
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 22:23:19 +03:00
extern const bool platform_uses_x11_unix_by_default;
Revamp of the local X11 connection code. We now parse X display strings more rigorously, and then we look up the local X authority data in .Xauthority _ourself_ rather than delegating to an external xauth program. This is (negligibly) more efficient on Unix, assuming I haven't got it wrong in some subtle way, but its major benefit is that we can now support X authority lookups on Windows as well provided the user points us at an appropriate X authority file in the standard format. A new Windows-specific config option has been added for this purpose. [originally from svn r8305]
2008-11-17 21:38:09 +03:00
/* choose default X transport in the absence of a specified one */
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 21:10:23 +03:00
SockAddr *platform_get_x11_unix_address(const char *path, int displaynum);
Revamp of the local X11 connection code. We now parse X display strings more rigorously, and then we look up the local X authority data in .Xauthority _ourself_ rather than delegating to an external xauth program. This is (negligibly) more efficient on Unix, assuming I haven't got it wrong in some subtle way, but its major benefit is that we can now support X authority lookups on Windows as well provided the user points us at an appropriate X authority file in the standard format. A new Windows-specific config option has been added for this purpose. [originally from svn r8305]
2008-11-17 21:38:09 +03:00
/* make up a SockAddr naming the address for displaynum */
X forwarding changes: - new function platform_get_x_display() to find a sensible local display. On Unix, the Gtk apps weren't taking account of --display when determining where to send forwarded X traffic. - explicitly document that leaving X display location blank in config tries to do something sensible (and that it's now blank by default) - don't override X11Display setting in plink, since that's more properly done later [originally from svn r4604]
2004-10-07 02:31:07 +04:00
char *platform_get_x_display(void);
Revamp of the local X11 connection code. We now parse X display strings more rigorously, and then we look up the local X authority data in .Xauthority _ourself_ rather than delegating to an external xauth program. This is (negligibly) more efficient on Unix, assuming I haven't got it wrong in some subtle way, but its major benefit is that we can now support X authority lookups on Windows as well provided the user points us at an appropriate X authority file in the standard format. A new Windows-specific config option has been added for this purpose. [originally from svn r8305]
2008-11-17 21:38:09 +03:00
/* allocated local X display string, if any */
/* Callbacks in x11.c usable _by_ platform X11 functions */
/*
* This function does the job of platform_get_x11_auth, provided
* it is told where to find a normally formatted .Xauthority file:
* it opens that file, parses it to find an auth record which
* matches the display details in "display", and fills in the
* localauth fields.
*
* It is expected that most implementations of
* platform_get_x11_auth() will work by finding their system's
* .Xauthority file, adjusting the display details if necessary
* for local oddities like Unix-domain socket transport, and
* calling this function to do the rest of the work.
*/
void x11_get_auth_from_authfile(struct X11Display *display,
const char *authfilename);
Server prep: routine to create a local X display. This will be used for the server side of X forwarding. It wraps up the mechanics of listening on the right TCP port and (if possible) the associated AF_UNIX socket, and also creates an appropriate X authority file containing authorisation data provided by its caller. Like the new platform_create_agent_socket, this function spawns a watchdog subprocess to clean up the mess afterwards, in the hope of at least _most_ of the time not leaving old sockets and authority files lying around /tmp,
2018-10-21 00:42:17 +03:00
void x11_format_auth_for_authfile(
BinarySink *bs, SockAddr *addr, int display_no,
ptrlen authproto, ptrlen authdata);
Rewrite packet parsing in sshshare.c using BinarySource. Another set of localised decoding routines get thrown away here. Also, I've changed the APIs of a couple of helper functions in x11fwd.c to take ptrlens in place of zero-terminated C strings, because that's the format in which they come back from the decode, and it saves mallocing a zero-terminated version of each one just to pass to those helpers.
2018-05-29 21:11:22 +03:00
int x11_identify_auth_proto(ptrlen protoname);
void *x11_dehexify(ptrlen hex, int *outlen);
Move the prototype for platform_get_x11_auth() from x11fwd.c to ssh.h so that it can be checked against the implementation. [originally from svn r2542]
2003-01-11 17:20:00 +03:00
Put a layer of abstraction in front of struct ssh_channel. Clients outside ssh.c - all implementations of Channel - will now not see the ssh_channel data type itself, but only a subobject of the interface type SshChannel. All the sshfwd_* functions have become methods in that interface type's vtable (though, wrapped in the usual kind of macros, the call sites look identical). This paves the way for me to split up the SSH-1 and SSH-2 connection layers and have each one lay out its channel bookkeeping structure as it sees fit; as long as they each provide an implementation of the sshfwd_ method family, the types behind that need not look different. A minor good effect of this is that the sshfwd_ methods are no longer global symbols, so they don't have to be stubbed in Unix Pageant to get it to compile.
2018-09-14 15:47:13 +03:00
Channel *agentf_new(SshChannel *c);
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 17:03:47 +03: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 09:51:44 +03:00
bool dh_is_gex(const ssh_kex *kex);
dh_ctx *dh_setup_group(const ssh_kex *kex);
dh_ctx *dh_setup_gex(mp_int *pval, mp_int *gval);
int dh_modulus_bit_size(const dh_ctx *ctx);
void dh_cleanup(dh_ctx *);
mp_int *dh_create_e(dh_ctx *, int nbits);
const char *dh_validate_f(dh_ctx *, mp_int *f);
mp_int *dh_find_K(dh_ctx *, mp_int *f);
RSA key authentication in ssh1 works; SSH2 is nearly there [originally from svn r572]
2000-09-07 20:33:49 +04:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
bool rsa_ssh1_encrypted(const Filename *filename, char **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 12:59:39 +03:00
int rsa_ssh1_loadpub(const Filename *filename, BinarySink *bs,
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 10:22:44 +03:00
char **commentptr, const char **errorstr);
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 09:51:44 +03:00
int rsa_ssh1_loadkey(const Filename *filename, RSAKey *key,
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 10:22:44 +03:00
const char *passphrase, const char **errorstr);
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 09:51:44 +03:00
bool rsa_ssh1_savekey(const Filename *filename, RSAKey *key, char *passphrase);
Preliminary support for RSA user authentication in SSH2! Most of the error messages are currently wrong, and Pageant doesn't yet support the new key type, and I haven't thoroughly tested that falling back to password authentication and trying invalid keys etc all work. But what I have here has successfully performed a public key authentication, so it's working to at least some extent. [originally from svn r973]
2001-03-03 14:54:34 +03:00
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 16:53:41 +03:00
static inline bool is_base64_char(char c)
{
return ((c >= '0' && c <= '9') ||
(c >= 'a' && c <= 'z') ||
(c >= 'A' && c <= 'Z') ||
c == '+' || c == '/' || c == '=');
}
Const-correctness in the base64 functions.
2015-05-12 16:00:04 +03:00
extern int base64_decode_atom(const char *atom, unsigned char *out);
Move prototypes for base64_decode_atom(), base64_lines(), and base64_encode() from import.c to ssh.h, so that the implementation can see them. This necessitates ssh.h's including <stdio.h>. Also remove a spare prototype for base64_encode_atom() from import.c. [originally from svn r2481]
2003-01-06 02:28:02 +03:00
extern int base64_lines(int datalen);
Const-correctness in the base64 functions.
2015-05-12 16:00:04 +03:00
extern void base64_encode_atom(const unsigned char *data, int n, char *out);
extern void base64_encode(FILE *fp, const unsigned char *data, int datalen,
int cpl);
Preliminary support for RSA user authentication in SSH2! Most of the error messages are currently wrong, and Pageant doesn't yet support the new key type, and I haven't thoroughly tested that falling back to password authentication and trying invalid keys etc all work. But what I have here has successfully performed a public key authentication, so it's working to at least some extent. [originally from svn r973]
2001-03-03 14:54:34 +03:00
/* ssh2_load_userkey can return this as an error */
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 09:51:44 +03:00
extern ssh2_userkey ssh2_wrong_passphrase;
Preliminary support for RSA user authentication in SSH2! Most of the error messages are currently wrong, and Pageant doesn't yet support the new key type, and I haven't thoroughly tested that falling back to password authentication and trying invalid keys etc all work. But what I have here has successfully performed a public key authentication, so it's working to at least some extent. [originally from svn r973]
2001-03-03 14:54:34 +03:00
#define SSH2_WRONG_PASSPHRASE (&ssh2_wrong_passphrase)
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
bool ssh2_userkey_encrypted(const Filename *filename, char **comment);
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 09:51:44 +03:00
ssh2_userkey *ssh2_load_userkey(
const Filename *filename, const char *passphrase, const char **errorstr);
bool ssh2_userkey_loadpub(
const Filename *filename, char **algorithm, BinarySink *bs,
char **commentptr, const char **errorstr);
bool ssh2_save_userkey(
const Filename *filename, ssh2_userkey *key, char *passphrase);
Invent a struct type for polymorphic SSH key data. During last week's work, I made a mistake in which I got the arguments backwards in one of the key-blob-generating functions - mistakenly swapped the 'void *' key instance with the 'BinarySink *' output destination - and I didn't spot the mistake until run time, because in C you can implicitly convert both to and from void * and so there was no compile-time failure of type checking. Now that I've introduced the FROMFIELD macro that downcasts a pointer to one field of a structure to retrieve a pointer to the whole structure, I think I might start using that more widely to indicate this kind of polymorphic subtyping. So now all the public-key functions in the struct ssh_signkey vtable handle their data instance in the form of a pointer to a subfield of a new zero-sized structure type 'ssh_key', which outside the key implementations indicates 'this is some kind of key instance but it could be of any type'; they downcast that pointer internally using FROMFIELD in place of the previous ordinary C cast, and return one by returning &foo->sshk for whatever foo they've just made up. The sshk member is not at the beginning of the structure, which means all those FROMFIELDs and &key->sshk are actually adding and subtracting an offset. Of course I could have put the member at the start anyway, but I had the idea that it's actually a feature _not_ to have the two types start at the same address, because it means you should notice earlier rather than later if you absentmindedly cast from one to the other directly rather than by the approved method (in particular, if you accidentally assign one through a void * and back without even _noticing_ you perpetrated a cast). In particular, this enforces that you can't sfree() the thing even once without realising you should instead of called the right freekey function. (I found several bugs by this method during initial testing, so I think it's already proved its worth!) While I'm here, I've also renamed the vtable structure ssh_signkey to ssh_keyalg, because it was a confusing name anyway - it describes the _algorithm_ for handling all keys of that type, not a specific key. So ssh_keyalg is the collection of code, and ssh_key is one instance of the data it handles.
2018-05-27 10:32:21 +03:00
const ssh_keyalg *find_pubkey_alg(const char *name);
Introduce a new 'ptrlen' type. This wraps up a (pointer, length) pair into a convenient struct that lets me return it by value from a function, and also pass it through to other functions in one go. Ideally quite a lot of this code base could be switched over to using ptrlen in place of separate pointer and length variables or function parameters. (In fact, in my personal ideal conception of C, the usual string type would be of this form, and all the string.h functions would operate on ptrlens instead of zero-terminated 'char *'.) For the moment, I'm just introducing it to make some upcoming refactoring less inconvenient. Bulk migration of existing code to ptrlen is a project for another time. Along with the type itself, I've provided a convenient system of including the contents of a ptrlen in a printf; a constructor function that wraps up a pointer and length so you can make a ptrlen on the fly in mid-expression; a function to compare a ptrlen against an ordinary C string (which I mostly expect to use with string literals); and a function 'mkstr' to make a dynamically allocated C string out of one. That last function replaces a function of the same name in sftp.c, which I'm promoting to a whole-codebase facility and adjusting its API.
2018-05-27 18:56:51 +03:00
const ssh_keyalg *find_pubkey_alg_len(ptrlen name);
Preliminary support for RSA user authentication in SSH2! Most of the error messages are currently wrong, and Pageant doesn't yet support the new key type, and I haven't thoroughly tested that falling back to password authentication and trying invalid keys etc all work. But what I have here has successfully performed a public key authentication, so it's working to at least some extent. [originally from svn r973]
2001-03-03 14:54:34 +03:00
Improved error messages if you use the wrong key type: you should now be told that the key is the wrong type, _and_ what type it is, rather than being given a blanket `unable to read key file' message. [originally from svn r1662]
2002-05-11 16:13:42 +04:00
enum {
SSH_KEYTYPE_UNOPENABLE,
SSH_KEYTYPE_UNKNOWN,
SSH_KEYTYPE_SSH1, SSH_KEYTYPE_SSH2,
Sort out the mess with OpenSSH key file formats. When I implemented reading and writing of the new format a couple of weeks ago, I kept them strictly separate in the UI, so you have to ask for the format you want when exporting. But in fact this is silly, because not every key type can be saved in both formats, and OpenSSH itself has the policy of using the old format for key types it can handle, unless specifically asked to use the new one. So I've now arranged that the key file format enum has three values for OpenSSH: PEM, NEW and AUTO. Files being loaded are identified as either PEM or NEW, which describe the two physical file formats. But exporting UIs present either AUTO or NEW, where AUTO is the virtual format meaning 'save in the old format if possible, otherwise the new one'.
2015-05-10 09:42:48 +03:00
/*
* The OpenSSH key types deserve a little explanation. OpenSSH has
* two physical formats for private key storage: an old PEM-based
* one largely dictated by their use of OpenSSL and full of ASN.1,
* and a new one using the same private key formats used over the
* wire for talking to ssh-agent. The old format can only support
* a subset of the key types, because it needs redesign for each
* key type, and after a while they decided to move to the new
* format so as not to have to do that.
*
* On input, key files are identified as either
* SSH_KEYTYPE_OPENSSH_PEM or SSH_KEYTYPE_OPENSSH_NEW, describing
* accurately which actual format the keys are stored in.
*
* On output, however, we default to following OpenSSH's own
* policy of writing out PEM-style keys for maximum backwards
* compatibility if the key type supports it, and otherwise
* switching to the new format. So the formats you can select for
* output are SSH_KEYTYPE_OPENSSH_NEW (forcing the new format for
* any key type), and SSH_KEYTYPE_OPENSSH_AUTO to use the oldest
* format supported by whatever key type you're writing out.
*
* So we have three type codes, but only two of them usable in any
* given circumstance. An input key file will never be identified
* as AUTO, only PEM or NEW; key export UIs should not be able to
* select PEM, only AUTO or NEW.
*/
SSH_KEYTYPE_OPENSSH_AUTO,
Separate key-type enum values for old and new OpenSSH keys. It's all very well for these two different formats to share a type code as long as we're only loading them and not saving, but as soon as we need to save one or the other, we'll need different type codes after all. This commit introduces the openssh_new_write() function, but for the moment, it always returns failure.
2015-04-28 21:46:58 +03:00
SSH_KEYTYPE_OPENSSH_PEM,
SSH_KEYTYPE_OPENSSH_NEW,
Support loading public-key-only files in Unix PuTTYgen. The rsakey_pubblob() and ssh2_userkey_loadpub() functions, which expected to be given a private key file and load only the unencrypted public half, now also cope with any of the public-only formats I know about (SSH-1 only has one, whereas SSH-2 has the RFC 4716 format and OpenSSH's one-line format) and return an appropriate public key blob from each of those too. cmdgen now supports this functionality, by permitting public key files to be loaded and used by any operation that doesn't need the private key: so you can convert back and forth between the SSH-2 public formats, or list the file's fingerprint.
2015-05-12 14:19:57 +03:00
SSH_KEYTYPE_SSHCOM,
/*
* Public-key-only formats, which we still want to be able to read
* for various purposes.
*/
SSH_KEYTYPE_SSH1_PUBLIC,
SSH_KEYTYPE_SSH2_PUBLIC_RFC4716,
SSH_KEYTYPE_SSH2_PUBLIC_OPENSSH
Improved error messages if you use the wrong key type: you should now be told that the key is the wrong type, _and_ what type it is, rather than being given a blanket `unable to read key file' message. [originally from svn r1662]
2002-05-11 16:13:42 +04: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 09:51:44 +03:00
char *ssh1_pubkey_str(RSAKey *ssh1key);
void ssh1_write_pubkey(FILE *fp, RSAKey *ssh1key);
char *ssh2_pubkey_openssh_str(ssh2_userkey *key);
Centralise public-key output code into sshpubk.c. There was a fair amount of duplication between Windows and Unix PuTTYgen, and some confusion over writing things to FILE * and formatting them internally into strings. I think all the public-key output code now lives in sshpubk.c, and there's only one copy of the code to generate each format.
2015-05-12 15:42:26 +03:00
void ssh2_write_pubkey(FILE *fp, const char *comment,
const void *v_pub_blob, int pub_len,
int keytype);
Assorted further migration to ptrlen. The local put_mp_*_from_string functions in import.c now take ptrlen (which simplifies essentially all their call sites); so does the local function logwrite() in logging.c, and so does ssh2_fingerprint_blob.
2019-02-06 23:48:03 +03:00
char *ssh2_fingerprint_blob(ptrlen);
Reorganise ssh_keyalg and use it as a vtable. After Pavel Kryukov pointed out that I have to put _something_ in the 'ssh_key' structure, I thought of an actually useful thing to put there: why not make it store a pointer to the ssh_keyalg structure? Then ssh_key becomes a classoid - or perhaps 'traitoid' is a closer analogy - in the same style as Socket and Plug. And just like Socket and Plug, I've also arranged a system of wrapper macros that avoid the need to mention the 'object' whose method you're invoking twice at each call site. The new vtable pointer directly replaces an existing field of struct ec_key (which was usable by several different ssh_keyalgs, so it already had to store a pointer to the currently active one), and also replaces the 'alg' field of the ssh2_userkey structure that wraps up a cryptographic key with its comment field. I've also taken the opportunity to clean things up a bit in general: most of the methods now have new and clearer names (e.g. you'd never know that 'newkey' made a public-only key while 'createkey' made a public+private key pair unless you went and looked it up, but now they're called 'new_pub' and 'new_priv' you might be in with a chance), and I've completely removed the openssh_private_npieces field after realising that it was duplicating information that is actually _more_ conveniently obtained by calling the new_priv_openssh method (formerly openssh_createkey) and throwing away the result.
2018-06-03 14:58:05 +03:00
char *ssh2_fingerprint(ssh_key *key);
Created new data types `Filename' and `FontSpec', intended to be opaque to all platform-independent modules and only handled within per-platform code. `Filename' is there because the Mac has a magic way to store filenames (though currently this checkin doesn't support it!); `FontSpec' is there so that all the auxiliary stuff such as font height and charset and so on which is needed under Windows but not Unix can be kept where it belongs, and so that I can have a hope in hell of dealing with a font chooser in the forthcoming cross-platform config box code, and best of all it gets the horrid font height wart out of settings.c and into the Windows code where it should be. The Mac part of this checkin is a bunch of random guesses which will probably not quite compile, but which look roughly right to me. Sorry if I screwed it up, Ben :-) [originally from svn r2765]
2003-02-01 15:54:40 +03:00
int key_type(const Filename *filename);
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 13:15:42 +03:00
const char *key_type_to_str(int type);
PuTTYgen initial version. Still to do are basic user-friendliness features (prompt for passphrase twice, prompt before overwriting a file, check the key file was actually saved OK), testing of the generated keys to make sure I got the file format right, and support for a variable key size. I think what's already here is basically sound though. [originally from svn r715]
2000-10-19 19:43:08 +04:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
bool import_possible(int type);
Added a framework for importing foreign key formats, and implemented importing of OpenSSH SSH2 private key files (both encrypted and unencrypted). Seems to work fine. [originally from svn r1668]
2002-05-11 20:45:29 +04:00
int import_target_type(int type);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
bool import_encrypted(const Filename *filename, int type, char **comment);
Created new data types `Filename' and `FontSpec', intended to be opaque to all platform-independent modules and only handled within per-platform code. `Filename' is there because the Mac has a magic way to store filenames (though currently this checkin doesn't support it!); `FontSpec' is there so that all the auxiliary stuff such as font height and charset and so on which is needed under Windows but not Unix can be kept where it belongs, and so that I can have a hope in hell of dealing with a font chooser in the forthcoming cross-platform config box code, and best of all it gets the horrid font height wart out of settings.c and into the Windows code where it should be. The Mac part of this checkin is a bunch of random guesses which will probably not quite compile, but which look roughly right to me. Sorry if I screwed it up, Ben :-) [originally from svn r2765]
2003-02-01 15:54:40 +03:00
int import_ssh1(const Filename *filename, int type,
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 09:51:44 +03:00
RSAKey *key, char *passphrase, const char **errmsg_p);
ssh2_userkey *import_ssh2(const Filename *filename, int type,
char *passphrase, const char **errmsg_p);
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 22:23:19 +03:00
bool export_ssh1(const Filename *filename, int type,
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 09:51:44 +03:00
RSAKey *key, char *passphrase);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
bool export_ssh2(const Filename *filename, int type,
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 09:51:44 +03:00
ssh2_userkey *key, char *passphrase);
Added a framework for importing foreign key formats, and implemented importing of OpenSSH SSH2 private key files (both encrypted and unencrypted). Seems to work fine. [originally from svn r1668]
2002-05-11 20:45:29 +04:00
Make lots of generic data parameters into 'void *'. This is a cleanup I started to notice a need for during the BinarySink work. It removes a lot of faffing about casting things to char * or unsigned char * so that some API will accept them, even though lots of such APIs really take a plain 'block of raw binary data' argument and don't care what C thinks the signedness of that data might be - they may well reinterpret it back and forth internally. So I've tried to arrange for all the function call APIs that ought to have a void * (or const void *) to have one, and those that need to do pointer arithmetic on the parameter internally can cast it back at the top of the function. That saves endless ad-hoc casts at the call sites.
2018-05-26 10:31:34 +03:00
void des3_decrypt_pubkey(const void *key, void *blk, int len);
void des3_encrypt_pubkey(const void *key, void *blk, int len);
void des3_decrypt_pubkey_ossh(const void *key, const void *iv,
void *blk, int len);
void des3_encrypt_pubkey_ossh(const void *key, const void *iv,
void *blk, int len);
void aes256_encrypt_pubkey(const void *key, void *blk, int len);
void aes256_decrypt_pubkey(const void *key, void *blk, int len);
void des_encrypt_xdmauth(const void *key, void *blk, int len);
void des_decrypt_xdmauth(const void *key, void *blk, int len);
Support XDM-AUTHORIZATION-1 for connecting to local X servers. If we're going to be a security program, we can at least make a token effort to use the most secure local X auth available! And I'm still half-tempted to see if I can support it for remote X servers too... [originally from svn r2537]
2003-01-11 12:31:54 +03:00
Implementation of OpenSSH's bcrypt. This isn't the same as the standard bcrypt; it's OpenSSH's modification that they use for their new-style key format. In order to implement this, I've broken up blowfish_setkey() into two subfunctions, and provided one of them with an extra optional salt parameter, which is NULL in ordinary Blowfish but used by bcrypt. Also, I've exposed some of sshblowf.c's internal machinery for the new sshbcrypt.c to use.
2015-04-27 22:48:29 +03:00
void openssh_bcrypt(const char *passphrase,
const unsigned char *salt, int saltbytes,
int rounds, unsigned char *out, int outbytes);
RSA key generation routines, and the bignum enhancements required to support them. A key generation tool will be forthcoming soon. [originally from svn r712]
2000-10-18 19:00:36 +04:00
/*
* For progress updates in the key generation utility.
*/
Remember to initialise p->nphases to zero in progress report structure. [originally from svn r1378]
2001-11-12 12:19:57 +03:00
#define PROGFN_INITIALISE 1
#define PROGFN_LIN_PHASE 2
#define PROGFN_EXP_PHASE 3
#define PROGFN_PHASE_EXTENT 4
#define PROGFN_READY 5
#define PROGFN_PROGRESS 6
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
typedef void (*progfn_t) (void *param, int action, int phase, int progress);
RSA key generation routines, and the bignum enhancements required to support them. A key generation tool will be forthcoming soon. [originally from svn r712]
2000-10-18 19:00:36 +04: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 09:51:44 +03:00
int rsa_generate(RSAKey *key, int bits, progfn_t pfn,
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 18:35:20 +04:00
void *pfnparam);
Add support for DSA authentication in SSH2, following clever ideas on how to get round the problem of generating a good k. [originally from svn r1284]
2001-09-23 00:52:21 +04:00
int dsa_generate(struct dss_key *key, int bits, progfn_t pfn,
void *pfnparam);
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 16:53:41 +03:00
int ecdsa_generate(struct ecdsa_key *key, int bits, progfn_t pfn,
void *pfnparam);
int eddsa_generate(struct eddsa_key *key, int bits, progfn_t pfn,
void *pfnparam);
mp_int *primegen(
int bits, int modulus, int residue, mp_int *factor,
int phase, progfn_t pfn, void *pfnparam, unsigned firstbits);
Rewrite invent_firstbits(). Instead of repeatedly looping on the random number generator until it comes up with two values that have a large enough product, the new version guarantees only one use of random numbers, by first counting up all the possible pairs of values that would work, and then inventing a single random number that's used as an index into that list. I've done the selection from the list using constant-time techniques, not particularly because I think key generation can be made CT in general, but out of sheer habit after the last few months, and who knows, it _might_ be useful. While I'm at it, I've also added an option to make sure the two firstbits values differ by at least a given value. For RSA, I set that value to 2, guaranteeing that even if the smaller prime has a very long string of 1 bits after the firstbits value and the larger has a long string of 0, they'll still have a relative difference of at least 2^{-12}. Not that there was any serious chance of the primes having randomly ended up so close together as to make the key in danger of factoring, but it seems like a silly thing to leave out if I'm rewriting the function anyway.
2019-02-26 10:06:57 +03:00
void invent_firstbits(unsigned *one, unsigned *two, unsigned min_separation);
Implement Zlib compression, in both SSH1 and SSH2. [originally from svn r792]
2000-11-02 00:34:21 +03:00
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 18:05:41 +04:00
/*
* Connection-sharing API provided by platforms. This function must
* either:
* - return SHARE_NONE and do nothing
* - return SHARE_DOWNSTREAM and set *sock to a Socket connected to
* downplug
* - return SHARE_UPSTREAM and set *sock to a Socket connected to
* upplug.
*/
enum { SHARE_NONE, SHARE_DOWNSTREAM, SHARE_UPSTREAM };
int platform_ssh_share(const char *name, Conf *conf,
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 21:10:23 +03:00
Plug *downplug, Plug *upplug, Socket **sock,
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 18:05:41 +04:00
char **logtext, char **ds_err, char **us_err,
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
bool can_upstream, bool can_downstream);
Implement connection sharing between instances of PuTTY. The basic strategy is described at the top of the new source file sshshare.c. In very brief: an 'upstream' PuTTY opens a Unix-domain socket or Windows named pipe, and listens for connections from other PuTTYs wanting to run sessions on the same server. The protocol spoken down that socket/pipe is essentially the bare ssh-connection protocol, using a trivial binary packet protocol with no encryption, and the upstream has to do some fiddly transformations that I've been referring to as 'channel-number NAT' to avoid resource clashes between the sessions it's managing. This is quite different from OpenSSH's approach of using the Unix- domain socket as a means of passing file descriptors around; the main reason for that is that fd-passing is Unix-specific but this system has to work on Windows too. However, there are additional advantages, such as making it easy for each downstream PuTTY to run its own independent set of port and X11 forwardings (though the method for making the latter work is quite painful). Sharing is off by default, but configuration is intended to be very easy in the normal case - just tick one box in the SSH config panel and everything else happens automatically. [originally from svn r10083]
2013-11-17 18:05:41 +04:00
void platform_ssh_share_cleanup(const char *name);
Move SSH protocol enumerations out into ssh.h. This permits packet type codes and other magic numbers to be accessed from modules other than ssh.c. [originally from svn r10064]
2013-11-17 18:03:29 +04:00
/*
Move SSH packet type codes into list macros. This allows me to share just one definition of the packet types between the enum declarations in ssh.h and the string translation functions in sshcommon.c. No functional change. The style of list macro is slightly unusual; instead of the traditional 'X-macro' in which LIST(X) expands to invocations of the form X(list element), this is an 'X-y macro', where LIST(X,y) expands to invocations of the form X(y, list element). That style makes it possible to wrap the list macro up in another macro and pass a parameter through from the wrapper to the per-element macro. I'm not using that facility just yet, but I will in the next commit.
2018-09-24 15:29:09 +03:00
* List macro defining the SSH-1 message type codes.
Move SSH protocol enumerations out into ssh.h. This permits packet type codes and other magic numbers to be accessed from modules other than ssh.c. [originally from svn r10064]
2013-11-17 18:03:29 +04:00
*/
Move SSH packet type codes into list macros. This allows me to share just one definition of the packet types between the enum declarations in ssh.h and the string translation functions in sshcommon.c. No functional change. The style of list macro is slightly unusual; instead of the traditional 'X-macro' in which LIST(X) expands to invocations of the form X(list element), this is an 'X-y macro', where LIST(X,y) expands to invocations of the form X(y, list element). That style makes it possible to wrap the list macro up in another macro and pass a parameter through from the wrapper to the per-element macro. I'm not using that facility just yet, but I will in the next commit.
2018-09-24 15:29:09 +03:00
#define SSH1_MESSAGE_TYPES(X, y) \
X(y, SSH1_MSG_DISCONNECT, 1) \
X(y, SSH1_SMSG_PUBLIC_KEY, 2) \
X(y, SSH1_CMSG_SESSION_KEY, 3) \
X(y, SSH1_CMSG_USER, 4) \
X(y, SSH1_CMSG_AUTH_RSA, 6) \
X(y, SSH1_SMSG_AUTH_RSA_CHALLENGE, 7) \
X(y, SSH1_CMSG_AUTH_RSA_RESPONSE, 8) \
X(y, SSH1_CMSG_AUTH_PASSWORD, 9) \
X(y, SSH1_CMSG_REQUEST_PTY, 10) \
X(y, SSH1_CMSG_WINDOW_SIZE, 11) \
X(y, SSH1_CMSG_EXEC_SHELL, 12) \
X(y, SSH1_CMSG_EXEC_CMD, 13) \
X(y, SSH1_SMSG_SUCCESS, 14) \
X(y, SSH1_SMSG_FAILURE, 15) \
X(y, SSH1_CMSG_STDIN_DATA, 16) \
X(y, SSH1_SMSG_STDOUT_DATA, 17) \
X(y, SSH1_SMSG_STDERR_DATA, 18) \
X(y, SSH1_CMSG_EOF, 19) \
X(y, SSH1_SMSG_EXIT_STATUS, 20) \
X(y, SSH1_MSG_CHANNEL_OPEN_CONFIRMATION, 21) \
X(y, SSH1_MSG_CHANNEL_OPEN_FAILURE, 22) \
X(y, SSH1_MSG_CHANNEL_DATA, 23) \
X(y, SSH1_MSG_CHANNEL_CLOSE, 24) \
X(y, SSH1_MSG_CHANNEL_CLOSE_CONFIRMATION, 25) \
X(y, SSH1_SMSG_X11_OPEN, 27) \
X(y, SSH1_CMSG_PORT_FORWARD_REQUEST, 28) \
X(y, SSH1_MSG_PORT_OPEN, 29) \
X(y, SSH1_CMSG_AGENT_REQUEST_FORWARDING, 30) \
X(y, SSH1_SMSG_AGENT_OPEN, 31) \
X(y, SSH1_MSG_IGNORE, 32) \
X(y, SSH1_CMSG_EXIT_CONFIRMATION, 33) \
X(y, SSH1_CMSG_X11_REQUEST_FORWARDING, 34) \
X(y, SSH1_CMSG_AUTH_RHOSTS_RSA, 35) \
X(y, SSH1_MSG_DEBUG, 36) \
X(y, SSH1_CMSG_REQUEST_COMPRESSION, 37) \
X(y, SSH1_CMSG_AUTH_TIS, 39) \
X(y, SSH1_SMSG_AUTH_TIS_CHALLENGE, 40) \
X(y, SSH1_CMSG_AUTH_TIS_RESPONSE, 41) \
X(y, SSH1_CMSG_AUTH_CCARD, 70) \
X(y, SSH1_SMSG_AUTH_CCARD_CHALLENGE, 71) \
X(y, SSH1_CMSG_AUTH_CCARD_RESPONSE, 72) \
/* end of list */
Move SSH protocol enumerations out into ssh.h. This permits packet type codes and other magic numbers to be accessed from modules other than ssh.c. [originally from svn r10064]
2013-11-17 18:03:29 +04:00
#define SSH1_AUTH_RHOSTS 1 /* 0x1 */
#define SSH1_AUTH_RSA 2 /* 0x2 */
#define SSH1_AUTH_PASSWORD 3 /* 0x3 */
#define SSH1_AUTH_RHOSTS_RSA 4 /* 0x4 */
#define SSH1_AUTH_TIS 5 /* 0x5 */
#define SSH1_AUTH_CCARD 16 /* 0x10 */
#define SSH1_PROTOFLAG_SCREEN_NUMBER 1 /* 0x1 */
/* Mask for protoflags we will echo back to server if seen */
#define SSH1_PROTOFLAGS_SUPPORTED 0 /* 0x1 */
/*
Move SSH packet type codes into list macros. This allows me to share just one definition of the packet types between the enum declarations in ssh.h and the string translation functions in sshcommon.c. No functional change. The style of list macro is slightly unusual; instead of the traditional 'X-macro' in which LIST(X) expands to invocations of the form X(list element), this is an 'X-y macro', where LIST(X,y) expands to invocations of the form X(y, list element). That style makes it possible to wrap the list macro up in another macro and pass a parameter through from the wrapper to the per-element macro. I'm not using that facility just yet, but I will in the next commit.
2018-09-24 15:29:09 +03:00
* List macro defining SSH-2 message type codes. Some of these depend
* on particular contexts (i.e. a previously negotiated kex or auth
* method)
Move SSH protocol enumerations out into ssh.h. This permits packet type codes and other magic numbers to be accessed from modules other than ssh.c. [originally from svn r10064]
2013-11-17 18:03:29 +04:00
*/
Move SSH packet type codes into list macros. This allows me to share just one definition of the packet types between the enum declarations in ssh.h and the string translation functions in sshcommon.c. No functional change. The style of list macro is slightly unusual; instead of the traditional 'X-macro' in which LIST(X) expands to invocations of the form X(list element), this is an 'X-y macro', where LIST(X,y) expands to invocations of the form X(y, list element). That style makes it possible to wrap the list macro up in another macro and pass a parameter through from the wrapper to the per-element macro. I'm not using that facility just yet, but I will in the next commit.
2018-09-24 15:29:09 +03:00
#define SSH2_MESSAGE_TYPES(X, K, A, y) \
X(y, SSH2_MSG_DISCONNECT, 1) \
X(y, SSH2_MSG_IGNORE, 2) \
X(y, SSH2_MSG_UNIMPLEMENTED, 3) \
X(y, SSH2_MSG_DEBUG, 4) \
X(y, SSH2_MSG_SERVICE_REQUEST, 5) \
X(y, SSH2_MSG_SERVICE_ACCEPT, 6) \
X(y, SSH2_MSG_KEXINIT, 20) \
X(y, SSH2_MSG_NEWKEYS, 21) \
K(y, SSH2_MSG_KEXDH_INIT, 30, SSH2_PKTCTX_DHGROUP) \
K(y, SSH2_MSG_KEXDH_REPLY, 31, SSH2_PKTCTX_DHGROUP) \
K(y, SSH2_MSG_KEX_DH_GEX_REQUEST_OLD, 30, SSH2_PKTCTX_DHGEX) \
K(y, SSH2_MSG_KEX_DH_GEX_REQUEST, 34, SSH2_PKTCTX_DHGEX) \
K(y, SSH2_MSG_KEX_DH_GEX_GROUP, 31, SSH2_PKTCTX_DHGEX) \
K(y, SSH2_MSG_KEX_DH_GEX_INIT, 32, SSH2_PKTCTX_DHGEX) \
K(y, SSH2_MSG_KEX_DH_GEX_REPLY, 33, SSH2_PKTCTX_DHGEX) \
K(y, SSH2_MSG_KEXGSS_INIT, 30, SSH2_PKTCTX_GSSKEX) \
K(y, SSH2_MSG_KEXGSS_CONTINUE, 31, SSH2_PKTCTX_GSSKEX) \
K(y, SSH2_MSG_KEXGSS_COMPLETE, 32, SSH2_PKTCTX_GSSKEX) \
K(y, SSH2_MSG_KEXGSS_HOSTKEY, 33, SSH2_PKTCTX_GSSKEX) \
K(y, SSH2_MSG_KEXGSS_ERROR, 34, SSH2_PKTCTX_GSSKEX) \
K(y, SSH2_MSG_KEXGSS_GROUPREQ, 40, SSH2_PKTCTX_GSSKEX) \
K(y, SSH2_MSG_KEXGSS_GROUP, 41, SSH2_PKTCTX_GSSKEX) \
K(y, SSH2_MSG_KEXRSA_PUBKEY, 30, SSH2_PKTCTX_RSAKEX) \
K(y, SSH2_MSG_KEXRSA_SECRET, 31, SSH2_PKTCTX_RSAKEX) \
K(y, SSH2_MSG_KEXRSA_DONE, 32, SSH2_PKTCTX_RSAKEX) \
Fix paste error in packet-type list macro. In commit 8cb68390e I managed to copy the packet contexts inaccurately from the old implementation of ssh2_pkt_type, and listed the ECDH KEX packets against SSH2_PKTCTX_DHGEX instead of SSH2_PKTCTX_ECDHKEX, which led to them appearing as "unknown" in packet log files.
2018-09-26 01:38:49 +03:00
K(y, SSH2_MSG_KEX_ECDH_INIT, 30, SSH2_PKTCTX_ECDHKEX) \
K(y, SSH2_MSG_KEX_ECDH_REPLY, 31, SSH2_PKTCTX_ECDHKEX) \
Move SSH packet type codes into list macros. This allows me to share just one definition of the packet types between the enum declarations in ssh.h and the string translation functions in sshcommon.c. No functional change. The style of list macro is slightly unusual; instead of the traditional 'X-macro' in which LIST(X) expands to invocations of the form X(list element), this is an 'X-y macro', where LIST(X,y) expands to invocations of the form X(y, list element). That style makes it possible to wrap the list macro up in another macro and pass a parameter through from the wrapper to the per-element macro. I'm not using that facility just yet, but I will in the next commit.
2018-09-24 15:29:09 +03:00
X(y, SSH2_MSG_USERAUTH_REQUEST, 50) \
X(y, SSH2_MSG_USERAUTH_FAILURE, 51) \
X(y, SSH2_MSG_USERAUTH_SUCCESS, 52) \
X(y, SSH2_MSG_USERAUTH_BANNER, 53) \
A(y, SSH2_MSG_USERAUTH_PK_OK, 60, SSH2_PKTCTX_PUBLICKEY) \
A(y, SSH2_MSG_USERAUTH_PASSWD_CHANGEREQ, 60, SSH2_PKTCTX_PASSWORD) \
A(y, SSH2_MSG_USERAUTH_INFO_REQUEST, 60, SSH2_PKTCTX_KBDINTER) \
A(y, SSH2_MSG_USERAUTH_INFO_RESPONSE, 61, SSH2_PKTCTX_KBDINTER) \
A(y, SSH2_MSG_USERAUTH_GSSAPI_RESPONSE, 60, SSH2_PKTCTX_GSSAPI) \
A(y, SSH2_MSG_USERAUTH_GSSAPI_TOKEN, 61, SSH2_PKTCTX_GSSAPI) \
A(y, SSH2_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, 63, SSH2_PKTCTX_GSSAPI) \
A(y, SSH2_MSG_USERAUTH_GSSAPI_ERROR, 64, SSH2_PKTCTX_GSSAPI) \
A(y, SSH2_MSG_USERAUTH_GSSAPI_ERRTOK, 65, SSH2_PKTCTX_GSSAPI) \
A(y, SSH2_MSG_USERAUTH_GSSAPI_MIC, 66, SSH2_PKTCTX_GSSAPI) \
X(y, SSH2_MSG_GLOBAL_REQUEST, 80) \
X(y, SSH2_MSG_REQUEST_SUCCESS, 81) \
X(y, SSH2_MSG_REQUEST_FAILURE, 82) \
X(y, SSH2_MSG_CHANNEL_OPEN, 90) \
X(y, SSH2_MSG_CHANNEL_OPEN_CONFIRMATION, 91) \
X(y, SSH2_MSG_CHANNEL_OPEN_FAILURE, 92) \
X(y, SSH2_MSG_CHANNEL_WINDOW_ADJUST, 93) \
X(y, SSH2_MSG_CHANNEL_DATA, 94) \
X(y, SSH2_MSG_CHANNEL_EXTENDED_DATA, 95) \
X(y, SSH2_MSG_CHANNEL_EOF, 96) \
X(y, SSH2_MSG_CHANNEL_CLOSE, 97) \
X(y, SSH2_MSG_CHANNEL_REQUEST, 98) \
X(y, SSH2_MSG_CHANNEL_SUCCESS, 99) \
X(y, SSH2_MSG_CHANNEL_FAILURE, 100) \
/* end of list */
#define DEF_ENUM_UNIVERSAL(y, name, value) name = value,
#define DEF_ENUM_CONTEXTUAL(y, name, value, context) name = value,
enum {
SSH1_MESSAGE_TYPES(DEF_ENUM_UNIVERSAL, y)
SSH2_MESSAGE_TYPES(DEF_ENUM_UNIVERSAL,
DEF_ENUM_CONTEXTUAL, DEF_ENUM_CONTEXTUAL, y)
/* Virtual packet type, for packets too short to even have a type */
SSH_MSG_NO_TYPE_CODE = 256
};
#undef DEF_ENUM_UNIVERSAL
#undef DEF_ENUM_CONTEXTUAL
Move binary packet protocols and censoring out of ssh.c. sshbpp.h now defines a classoid that encapsulates both directions of an SSH binary packet protocol - that is, a system for reading a bufchain of incoming data and turning it into a stream of PktIn, and another system for taking a PktOut and turning it into data on an outgoing bufchain. The state structure in each of those files contains everything that used to be in the 'rdpkt2_state' structure and its friends, and also quite a lot of bits and pieces like cipher and MAC states that used to live in the main Ssh structure. One minor effect of this layer separation is that I've had to extend the packet dispatch table by one, because the BPP layer can no longer directly trigger sending of SSH_MSG_UNIMPLEMENTED for a message too short to have a type byte. Instead, I extend the PktIn type field to use an out-of-range value to encode that, and the easiest way to make that trigger an UNIMPLEMENTED message is to have the dispatch table contain an entry for it. (That's a system that may come in useful again - I was also wondering about inventing a fake type code to indicate network EOF, so that that could be propagated through the layers and be handled by whichever one currently knew best how to respond.) I've also moved the packet-censoring code into its own pair of files, partly because I was going to want to do that anyway sooner or later, and mostly because it's called from the BPP code, and the SSH-2 version in particular has to be called from both the main SSH-2 BPP and the bare unencrypted protocol used for connection sharing. While I was at it, I took the opportunity to merge the outgoing and incoming censor functions, so that the parts that were common between them (e.g. CHANNEL_DATA messages look the same in both directions) didn't need to be repeated.
2018-06-09 11:09:10 +03:00
SSH2 can now use Pageant to obtain keys from [originally from svn r977]
2001-03-03 18:56:39 +03:00
/*
Consistently use a single notation to refer to SSH protocol versions, as discussed. Use Barrett and Silverman's convention of "SSH-1" for SSH protocol version 1 and "SSH-2" for protocol 2 ("SSH1"/"SSH2" refer to ssh.com implementations in this scheme). <http://www.snailbook.com/terms.html> [originally from svn r5480]
2005-03-10 19:36:05 +03:00
* SSH-1 agent messages.
SSH2 can now use Pageant to obtain keys from [originally from svn r977]
2001-03-03 18:56:39 +03:00
*/
#define SSH1_AGENTC_REQUEST_RSA_IDENTITIES 1
#define SSH1_AGENT_RSA_IDENTITIES_ANSWER 2
#define SSH1_AGENTC_RSA_CHALLENGE 3
#define SSH1_AGENT_RSA_RESPONSE 4
#define SSH1_AGENTC_ADD_RSA_IDENTITY 7
#define SSH1_AGENTC_REMOVE_RSA_IDENTITY 8
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 18:35:20 +04:00
#define SSH1_AGENTC_REMOVE_ALL_RSA_IDENTITIES 9 /* openssh private? */
SSH2 can now use Pageant to obtain keys from [originally from svn r977]
2001-03-03 18:56:39 +03:00
/*
Consistently use a single notation to refer to SSH protocol versions, as discussed. Use Barrett and Silverman's convention of "SSH-1" for SSH protocol version 1 and "SSH-2" for protocol 2 ("SSH1"/"SSH2" refer to ssh.com implementations in this scheme). <http://www.snailbook.com/terms.html> [originally from svn r5480]
2005-03-10 19:36:05 +03:00
* Messages common to SSH-1 and OpenSSH's SSH-2.
SSH2 can now use Pageant to obtain keys from [originally from svn r977]
2001-03-03 18:56:39 +03:00
*/
#define SSH_AGENT_FAILURE 5
#define SSH_AGENT_SUCCESS 6
/*
Consistently use a single notation to refer to SSH protocol versions, as discussed. Use Barrett and Silverman's convention of "SSH-1" for SSH protocol version 1 and "SSH-2" for protocol 2 ("SSH1"/"SSH2" refer to ssh.com implementations in this scheme). <http://www.snailbook.com/terms.html> [originally from svn r5480]
2005-03-10 19:36:05 +03:00
* OpenSSH's SSH-2 agent messages.
SSH2 can now use Pageant to obtain keys from [originally from svn r977]
2001-03-03 18:56:39 +03:00
*/
#define SSH2_AGENTC_REQUEST_IDENTITIES 11
#define SSH2_AGENT_IDENTITIES_ANSWER 12
#define SSH2_AGENTC_SIGN_REQUEST 13
#define SSH2_AGENT_SIGN_RESPONSE 14
#define SSH2_AGENTC_ADD_IDENTITY 17
#define SSH2_AGENTC_REMOVE_IDENTITY 18
#define SSH2_AGENTC_REMOVE_ALL_IDENTITIES 19
INCOMPATIBLE CHANGE to the SSH2 private key file format. There is now a passphrase-keyed MAC covering _all_ important data in the file, including the public blob and the key comment. Should conclusively scupper any attacks based on nobbling the key file in an attempt to sucker the machine that decrypts it. MACing the comment field also protects against a key-substitution attack (if someone's worked out a way past our DSA protections and can extract the private key from a signature, swapping key files and substituting comments might just enable them to get the signature they need to do this. Paranoid, but might as well). [originally from svn r1413]
2001-11-25 17:31:46 +03:00
Move SSH protocol enumerations out into ssh.h. This permits packet type codes and other magic numbers to be accessed from modules other than ssh.c. [originally from svn r10064]
2013-11-17 18:03:29 +04:00
/*
* Assorted other SSH-related enumerations.
*/
#define SSH2_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 /* 0x1 */
#define SSH2_DISCONNECT_PROTOCOL_ERROR 2 /* 0x2 */
#define SSH2_DISCONNECT_KEY_EXCHANGE_FAILED 3 /* 0x3 */
#define SSH2_DISCONNECT_HOST_AUTHENTICATION_FAILED 4 /* 0x4 */
#define SSH2_DISCONNECT_MAC_ERROR 5 /* 0x5 */
#define SSH2_DISCONNECT_COMPRESSION_ERROR 6 /* 0x6 */
#define SSH2_DISCONNECT_SERVICE_NOT_AVAILABLE 7 /* 0x7 */
#define SSH2_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 /* 0x8 */
#define SSH2_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 /* 0x9 */
#define SSH2_DISCONNECT_CONNECTION_LOST 10 /* 0xa */
#define SSH2_DISCONNECT_BY_APPLICATION 11 /* 0xb */
#define SSH2_DISCONNECT_TOO_MANY_CONNECTIONS 12 /* 0xc */
#define SSH2_DISCONNECT_AUTH_CANCELLED_BY_USER 13 /* 0xd */
#define SSH2_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 /* 0xe */
#define SSH2_DISCONNECT_ILLEGAL_USER_NAME 15 /* 0xf */
#define SSH2_OPEN_ADMINISTRATIVELY_PROHIBITED 1 /* 0x1 */
#define SSH2_OPEN_CONNECT_FAILED 2 /* 0x2 */
#define SSH2_OPEN_UNKNOWN_CHANNEL_TYPE 3 /* 0x3 */
#define SSH2_OPEN_RESOURCE_SHORTAGE 4 /* 0x4 */
#define SSH2_EXTENDED_DATA_STDERR 1 /* 0x1 */
New system for handling SSH terminal modes. I've introduced a new POD struct type 'ssh_ttymodes' which stores an encoding of everything you can specify in the "pty-req" packet or the SSH-1 equivalent. This allows me to split up write_ttymodes_to_packet_from_conf() into two separate functions, one to parse all the ttymode data out of a Conf (and a Seat for fallback) and return one of those structures, and the other to write it into an SSH packet. While I'm at it, I've moved the special case of terminal speeds into the same mechanism, simplifying the call sites in both versions of the SSH protocol. The new master definition of all terminal modes lives in a header file, with an ifdef around each item, so that later on I'll be able to include it in a context that only enumerates the modes supported by the particular target Unix platform.
2018-10-12 21:25:59 +03:00
enum {
/* TTY modes with opcodes defined consistently in the SSH specs. */
#define TTYMODE_CHAR(name, val, index) SSH_TTYMODE_##name = val,
#define TTYMODE_FLAG(name, val, field, mask) SSH_TTYMODE_##name = val,
#include "sshttymodes.h"
#undef TTYMODE_CHAR
#undef TTYMODE_FLAG
/* Modes encoded differently between SSH-1 and SSH-2, for which we
* make up our own dummy opcodes to avoid confusion. */
TTYMODE_dummy = 255,
TTYMODE_ISPEED, TTYMODE_OSPEED,
/* Limiting value that we can use as an array bound below */
TTYMODE_LIMIT,
/* The real opcodes for terminal speeds. */
TTYMODE_ISPEED_SSH1 = 192,
TTYMODE_OSPEED_SSH1 = 193,
TTYMODE_ISPEED_SSH2 = 128,
TTYMODE_OSPEED_SSH2 = 129,
/* And the opcode that ends a list. */
TTYMODE_END_OF_LIST = 0
};
struct ssh_ttymodes {
/* A boolean per mode, indicating whether it's set. */
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 22:23:19 +03:00
bool have_mode[TTYMODE_LIMIT];
New system for handling SSH terminal modes. I've introduced a new POD struct type 'ssh_ttymodes' which stores an encoding of everything you can specify in the "pty-req" packet or the SSH-1 equivalent. This allows me to split up write_ttymodes_to_packet_from_conf() into two separate functions, one to parse all the ttymode data out of a Conf (and a Seat for fallback) and return one of those structures, and the other to write it into an SSH packet. While I'm at it, I've moved the special case of terminal speeds into the same mechanism, simplifying the call sites in both versions of the SSH protocol. The new master definition of all terminal modes lives in a header file, with an ifdef around each item, so that later on I'll be able to include it in a context that only enumerates the modes supported by the particular target Unix platform.
2018-10-12 21:25:59 +03:00
/* The actual value for each mode. */
unsigned mode_val[TTYMODE_LIMIT];
};
struct ssh_ttymodes get_ttymodes_from_conf(Seat *seat, Conf *conf);
Server prep: parse a lot of new channel requests. ssh2connection.c now knows how to unmarshal the message formats for all the channel requests we'll need to handle when we're the server and a client sends them. Each one is translated into a call to a new method in the Channel vtable, which is implemented by a trivial 'always fail' routine in every channel type we know about so far.
2018-10-20 23:48:49 +03:00
struct ssh_ttymodes read_ttymodes_from_packet(
BinarySource *bs, int ssh_version);
New system for handling SSH terminal modes. I've introduced a new POD struct type 'ssh_ttymodes' which stores an encoding of everything you can specify in the "pty-req" packet or the SSH-1 equivalent. This allows me to split up write_ttymodes_to_packet_from_conf() into two separate functions, one to parse all the ttymode data out of a Conf (and a Seat for fallback) and return one of those structures, and the other to write it into an SSH packet. While I'm at it, I've moved the special case of terminal speeds into the same mechanism, simplifying the call sites in both versions of the SSH protocol. The new master definition of all terminal modes lives in a header file, with an ifdef around each item, so that later on I'll be able to include it in a context that only enumerates the modes supported by the particular target Unix platform.
2018-10-12 21:25:59 +03:00
void write_ttymodes_to_packet(BinarySink *bs, int ssh_version,
struct ssh_ttymodes modes);
Move some ssh.c declarations into header files. ssh.c has been an unmanageably huge monolith of a source file for too long, and it's finally time I started breaking it up into smaller pieces. The first step is to move some declarations - basic types like packets and packet queues, standard constants, enums, and the coroutine system - into headers where other files can see them.
2018-06-09 11:07:18 +03:00
const char *ssh1_pkt_type(int type);
const char *ssh2_pkt_type(Pkt_KCtx pkt_kctx, Pkt_ACtx pkt_actx, int type);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
bool ssh2_pkt_type_code_valid(unsigned type);
Move some ssh.c declarations into header files. ssh.c has been an unmanageably huge monolith of a source file for too long, and it's finally time I started breaking it up into smaller pieces. The first step is to move some declarations - basic types like packets and packet queues, standard constants, enums, and the coroutine system - into headers where other files can see them.
2018-06-09 11:07:18 +03:00
INCOMPATIBLE CHANGE to the SSH2 private key file format. There is now a passphrase-keyed MAC covering _all_ important data in the file, including the public blob and the key comment. Should conclusively scupper any attacks based on nobbling the key file in an attempt to sucker the machine that decrypts it. MACing the comment field also protects against a key-substitution attack (if someone's worked out a way past our DSA protections and can extract the private key from a signature, swapping key files and substituting comments might just enable them to get the signature they need to do this. Paranoid, but might as well). [originally from svn r1413]
2001-11-25 17:31:46 +03:00
/*
Consistently use a single notation to refer to SSH protocol versions, as discussed. Use Barrett and Silverman's convention of "SSH-1" for SSH protocol version 1 and "SSH-2" for protocol 2 ("SSH1"/"SSH2" refer to ssh.com implementations in this scheme). <http://www.snailbook.com/terms.html> [originally from svn r5480]
2005-03-10 19:36:05 +03:00
* Need this to warn about support for the original SSH-2 keyfile
INCOMPATIBLE CHANGE to the SSH2 private key file format. There is now a passphrase-keyed MAC covering _all_ important data in the file, including the public blob and the key comment. Should conclusively scupper any attacks based on nobbling the key file in an attempt to sucker the machine that decrypts it. MACing the comment field also protects against a key-substitution attack (if someone's worked out a way past our DSA protections and can extract the private key from a signature, swapping key files and substituting comments might just enable them to get the signature they need to do this. Paranoid, but might as well). [originally from svn r1413]
2001-11-25 17:31:46 +03:00
* format.
*/
void old_keyfile_warning(void);
Move bug flag definitions out into ssh.h. With a new shiny list-macro system that will allocate power-of-2 values for them without me having to manually keep the numbers straight.
2018-09-19 19:59:38 +03:00
/*
* Flags indicating implementation bugs that we know how to mitigate
* if we think the other end has them.
*/
#define SSH_IMPL_BUG_LIST(X) \
X(BUG_CHOKES_ON_SSH1_IGNORE) \
X(BUG_SSH2_HMAC) \
X(BUG_NEEDS_SSH1_PLAIN_PASSWORD) \
X(BUG_CHOKES_ON_RSA) \
X(BUG_SSH2_RSA_PADDING) \
X(BUG_SSH2_DERIVEKEY) \
X(BUG_SSH2_REKEY) \
X(BUG_SSH2_PK_SESSIONID) \
X(BUG_SSH2_MAXPKT) \
X(BUG_CHOKES_ON_SSH2_IGNORE) \
X(BUG_CHOKES_ON_WINADJ) \
X(BUG_SENDS_LATE_REQUEST_REPLY) \
X(BUG_SSH2_OLDGEX) \
/* end of list */
#define TMP_DECLARE_LOG2_ENUM(thing) log2_##thing,
enum { SSH_IMPL_BUG_LIST(TMP_DECLARE_LOG2_ENUM) };
#undef TMP_DECLARE_LOG2_ENUM
#define TMP_DECLARE_REAL_ENUM(thing) thing = 1 << log2_##thing,
enum { SSH_IMPL_BUG_LIST(TMP_DECLARE_REAL_ENUM) };
#undef TMP_DECLARE_REAL_ENUM
Move the ttymode formatter into sshcommon.c. While I'm at it, I've brought it all into a single function: the parsing of data from Conf, the list of modes, and even the old callback system for writing to the destination buffer is now a simple if statement that formats mode parameters as byte or uint32 depending on SSH version. Also, the terminal speeds and the end byte are part of the same setup, so it's all together in one place instead of scattered all over ssh.c.
2018-09-19 22:36:40 +03:00
Move alloc_channel_id into sshcommon.c. That function _did_ depend on ssh.c's internal facilities, namely the layout of 'struct ssh_channel'. In place of that, it now takes an extra integer argument telling it where to find the channel id in whatever data structure you give it a tree of - so now I can split up the SSH-1 and SSH-2 channel handling without losing the services of that nice channel-number allocator.
2018-09-19 22:37:12 +03:00
/* Shared system for allocating local SSH channel ids. Expects to be
* passed a tree full of structs that have a field called 'localid' of
* type unsigned, and will check that! */
unsigned alloc_channel_id_general(tree234 *channels, size_t localid_offset);
#define alloc_channel_id(tree, type) \
TYPECHECK(&((type *)0)->localid == (unsigned *)0, \
alloc_channel_id_general(tree, offsetof(type, localid)))
Move comma-separated string functions into sshcommon.c. These are just string handling, after all. They could even move into misc.c if any non-SSH-related code ever had a need for them.
2018-09-19 22:39:25 +03:00
void add_to_commasep(strbuf *buf, const char *data);
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 22:23:19 +03:00
bool get_commasep_word(ptrlen *list, ptrlen *word);
Move verify_ssh_manual_host_key into sshcommon.c This is essentially trivial, because the only thing it needed from the Ssh structure was the Conf. So the version in sshcommon.c just takes an actual Conf as an argument, and now it doesn't need access to the big structure definition any more.
2018-09-24 16:15:32 +03:00
int verify_ssh_manual_host_key(
Conf *conf, const char *fingerprint, ssh_key *key);
Move transient host key cache into its own file. This is a nice standalone piece of code which doesn't really have to appear in the middle of ssh2transport.
2018-10-06 15:32:17 +03:00
typedef struct ssh_transient_hostkey_cache ssh_transient_hostkey_cache;
ssh_transient_hostkey_cache *ssh_transient_hostkey_cache_new(void);
void ssh_transient_hostkey_cache_free(ssh_transient_hostkey_cache *thc);
void ssh_transient_hostkey_cache_add(
ssh_transient_hostkey_cache *thc, ssh_key *key);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
bool ssh_transient_hostkey_cache_verify(
Move transient host key cache into its own file. This is a nice standalone piece of code which doesn't really have to appear in the middle of ssh2transport.
2018-10-06 15:32:17 +03:00
ssh_transient_hostkey_cache *thc, ssh_key *key);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 22:23:19 +03:00
bool ssh_transient_hostkey_cache_has(
Move transient host key cache into its own file. This is a nice standalone piece of code which doesn't really have to appear in the middle of ssh2transport.
2018-10-06 15:32:17 +03:00
ssh_transient_hostkey_cache *thc, const ssh_keyalg *alg);
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 22:23:19 +03:00
bool ssh_transient_hostkey_cache_non_empty(ssh_transient_hostkey_cache *thc);