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

1359 lines
48 KiB
C
Raw Normal View History

Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
/*
* cmdgen.c - command-line form of PuTTYgen
*/
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <limits.h>
#include <assert.h>
#include <time.h>
Add command-line passphrase-file options to command-line PuTTYgen. Patch due to Colin Watson. Putting the passphrase in a file avoids exposing it to 'ps' which can print out every process's command line, while at the same time not being as platform-specific as the approach of providing an fd number (since cmdgen.c is in principle a potential cross-platform PuTTYgen, not just a Unix one, which is why it's not in the 'unix' directory). Of course it introduces its own risks if someone can read the file from your disk after you delete it; probably the best approach to avoiding this, if possible, is to point the option at a file on an in-memory tmpfs type file system. Or better still, use bash-style /dev/fd options such as puttygen --new-passphrase <(echo -n "my passphrase") [options] Failing that, try a secure file-wipe utility, as the man page change mentions. (And a use case not to be overlooked, of course, is the one where you actually want to generate an unprotected key - in which case, just pass /dev/null as the filename.)
2016-03-17 18:42:46 +00:00
#include <errno.h>
#include <string.h>
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
#include "putty.h"
#include "ssh.h"
New vtable API for keygen progress reporting. The old API was one of those horrible things I used to do when I was young and foolish, in which you have just one function, and indicate which of lots of things it's doing by passing in flags. It was crying out to be replaced with a vtable. While I'm at it, I've reworked the code on the Windows side that decides what to do with the progress bar, so that it's based on actually justifiable estimates of probability rather than magic integer constants. Since computers are generally faster now than they were at the start of this project, I've also decided there's no longer any point in making the fixed final part of RSA key generation bother to report progress at all. So the progress bars are now only for the variable part, i.e. the actual prime generations. (This is a reapplication of commit a7bdefb39, without the Miller-Rabin refactoring accidentally folded into it. Also this time I've added -lm to the link options, which for some reason _didn't_ cause me a link failure last time round. No idea why not.)
2020-02-23 15:29:40 +00:00
#include "sshkeygen.h"
cmdgen: add a --dump option. Also spelled '-O text', this takes a public or private key as input, and produces on standard output a dump of all the actual numbers involved in the key: the exponent and modulus for RSA, the p,q,g,y parameters for DSA, the affine x and y coordinates of the public elliptic curve point for ECC keys, and all the extra bits and pieces in the private keys too. Partly I expect this to be useful to me for debugging: I've had to paste key files a few too many times through base64 decoders and hex dump tools, then manually decode SSH marshalling and paste the result into the Python REPL to get an integer object. Now I should be able to get _straight_ to text I can paste into Python. But also, it's a way that other applications can use the key generator: if you need to generate, say, an RSA key in some format I don't support (I've recently heard of an XML-based one, for example), then you can run 'puttygen -t rsa --dump' and have it print the elements of a freshly generated keypair on standard output, and then all you have to do is understand the output format.
2020-02-17 19:53:19 +00:00
#include "mpint.h"
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
Add linear mode to the new progress reporting system. The old system I removed in commit 79d3c1783b had both linear and exponential phase types, but the new one only had exponential, because at that point I'd just thrown away all the clients of the linear phase type. But I'm going to add another one shortly, so I have to put it back in.
2020-02-29 17:11:01 +00:00
static FILE *progress_fp = NULL;
static bool linear_progress_phase;
static unsigned last_progress_col;
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
Add linear mode to the new progress reporting system. The old system I removed in commit 79d3c1783b had both linear and exponential phase types, but the new one only had exponential, because at that point I'd just thrown away all the clients of the linear phase type. But I'm going to add another one shortly, so I have to put it back in.
2020-02-29 17:11:01 +00:00
static ProgressPhase cmdgen_progress_add_linear(
ProgressReceiver *prog, double c)
{
ProgressPhase ph = { .n = 0 };
return ph;
}
static ProgressPhase cmdgen_progress_add_probabilistic(
ProgressReceiver *prog, double c, double p)
{
ProgressPhase ph = { .n = 1 };
return ph;
}
static void cmdgen_progress_start_phase(ProgressReceiver *prog,
ProgressPhase p)
{
linear_progress_phase = (p.n == 0);
last_progress_col = 0;
}
static void cmdgen_progress_report(ProgressReceiver *prog, double p)
{
unsigned new_col = p * 64 + 0.5;
for (; last_progress_col < new_col; last_progress_col++)
fputc('+', progress_fp);
}
New vtable API for keygen progress reporting. The old API was one of those horrible things I used to do when I was young and foolish, in which you have just one function, and indicate which of lots of things it's doing by passing in flags. It was crying out to be replaced with a vtable. While I'm at it, I've reworked the code on the Windows side that decides what to do with the progress bar, so that it's based on actually justifiable estimates of probability rather than magic integer constants. Since computers are generally faster now than they were at the start of this project, I've also decided there's no longer any point in making the fixed final part of RSA key generation bother to report progress at all. So the progress bars are now only for the variable part, i.e. the actual prime generations. (This is a reapplication of commit a7bdefb39, without the Miller-Rabin refactoring accidentally folded into it. Also this time I've added -lm to the link options, which for some reason _didn't_ cause me a link failure last time round. No idea why not.)
2020-02-23 15:29:40 +00:00
static void cmdgen_progress_report_attempt(ProgressReceiver *prog)
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
{
New vtable API for keygen progress reporting. The old API was one of those horrible things I used to do when I was young and foolish, in which you have just one function, and indicate which of lots of things it's doing by passing in flags. It was crying out to be replaced with a vtable. While I'm at it, I've reworked the code on the Windows side that decides what to do with the progress bar, so that it's based on actually justifiable estimates of probability rather than magic integer constants. Since computers are generally faster now than they were at the start of this project, I've also decided there's no longer any point in making the fixed final part of RSA key generation bother to report progress at all. So the progress bars are now only for the variable part, i.e. the actual prime generations. (This is a reapplication of commit a7bdefb39, without the Miller-Rabin refactoring accidentally folded into it. Also this time I've added -lm to the link options, which for some reason _didn't_ cause me a link failure last time round. No idea why not.)
2020-02-23 15:29:40 +00:00
if (progress_fp) {
fputc('+', progress_fp);
fflush(progress_fp);
New vtable API for keygen progress reporting. The old API was one of those horrible things I used to do when I was young and foolish, in which you have just one function, and indicate which of lots of things it's doing by passing in flags. It was crying out to be replaced with a vtable. While I'm at it, I've reworked the code on the Windows side that decides what to do with the progress bar, so that it's based on actually justifiable estimates of probability rather than magic integer constants. Since computers are generally faster now than they were at the start of this project, I've also decided there's no longer any point in making the fixed final part of RSA key generation bother to report progress at all. So the progress bars are now only for the variable part, i.e. the actual prime generations.
2020-02-23 15:29:40 +00:00
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
New vtable API for keygen progress reporting. The old API was one of those horrible things I used to do when I was young and foolish, in which you have just one function, and indicate which of lots of things it's doing by passing in flags. It was crying out to be replaced with a vtable. While I'm at it, I've reworked the code on the Windows side that decides what to do with the progress bar, so that it's based on actually justifiable estimates of probability rather than magic integer constants. Since computers are generally faster now than they were at the start of this project, I've also decided there's no longer any point in making the fixed final part of RSA key generation bother to report progress at all. So the progress bars are now only for the variable part, i.e. the actual prime generations. (This is a reapplication of commit a7bdefb39, without the Miller-Rabin refactoring accidentally folded into it. Also this time I've added -lm to the link options, which for some reason _didn't_ cause me a link failure last time round. No idea why not.)
2020-02-23 15:29:40 +00:00
static void cmdgen_progress_report_phase_complete(ProgressReceiver *prog)
Revert "New vtable API for keygen progress reporting." This reverts commit a7bdefb3942fec5fca41bfa46d77d70b1d6e4fd2. I had accidentally mashed it together with another commit. I did actually want to push both of them, but I'd rather push them separately! So I'm backing out the combined blob, and I'll re-push them with their proper comments and explanations.
2020-02-29 16:32:16 +00:00
{
Add linear mode to the new progress reporting system. The old system I removed in commit 79d3c1783b had both linear and exponential phase types, but the new one only had exponential, because at that point I'd just thrown away all the clients of the linear phase type. But I'm going to add another one shortly, so I have to put it back in.
2020-02-29 17:11:01 +00:00
if (linear_progress_phase)
cmdgen_progress_report(prog, 1.0);
New vtable API for keygen progress reporting. The old API was one of those horrible things I used to do when I was young and foolish, in which you have just one function, and indicate which of lots of things it's doing by passing in flags. It was crying out to be replaced with a vtable. While I'm at it, I've reworked the code on the Windows side that decides what to do with the progress bar, so that it's based on actually justifiable estimates of probability rather than magic integer constants. Since computers are generally faster now than they were at the start of this project, I've also decided there's no longer any point in making the fixed final part of RSA key generation bother to report progress at all. So the progress bars are now only for the variable part, i.e. the actual prime generations. (This is a reapplication of commit a7bdefb39, without the Miller-Rabin refactoring accidentally folded into it. Also this time I've added -lm to the link options, which for some reason _didn't_ cause me a link failure last time round. No idea why not.)
2020-02-23 15:29:40 +00:00
if (progress_fp) {
fputc('\n', progress_fp);
fflush(progress_fp);
}
Revert "New vtable API for keygen progress reporting." This reverts commit a7bdefb3942fec5fca41bfa46d77d70b1d6e4fd2. I had accidentally mashed it together with another commit. I did actually want to push both of them, but I'd rather push them separately! So I'm backing out the combined blob, and I'll re-push them with their proper comments and explanations.
2020-02-29 16:32:16 +00:00
}
New vtable API for keygen progress reporting. The old API was one of those horrible things I used to do when I was young and foolish, in which you have just one function, and indicate which of lots of things it's doing by passing in flags. It was crying out to be replaced with a vtable. While I'm at it, I've reworked the code on the Windows side that decides what to do with the progress bar, so that it's based on actually justifiable estimates of probability rather than magic integer constants. Since computers are generally faster now than they were at the start of this project, I've also decided there's no longer any point in making the fixed final part of RSA key generation bother to report progress at all. So the progress bars are now only for the variable part, i.e. the actual prime generations.
2020-02-23 15:29:40 +00:00
New vtable API for keygen progress reporting. The old API was one of those horrible things I used to do when I was young and foolish, in which you have just one function, and indicate which of lots of things it's doing by passing in flags. It was crying out to be replaced with a vtable. While I'm at it, I've reworked the code on the Windows side that decides what to do with the progress bar, so that it's based on actually justifiable estimates of probability rather than magic integer constants. Since computers are generally faster now than they were at the start of this project, I've also decided there's no longer any point in making the fixed final part of RSA key generation bother to report progress at all. So the progress bars are now only for the variable part, i.e. the actual prime generations. (This is a reapplication of commit a7bdefb39, without the Miller-Rabin refactoring accidentally folded into it. Also this time I've added -lm to the link options, which for some reason _didn't_ cause me a link failure last time round. No idea why not.)
2020-02-23 15:29:40 +00:00
static const ProgressReceiverVtable cmdgen_progress_vt = {
Change vtable defs to use C99 designated initialisers. This is a sweeping change applied across the whole code base by a spot of Emacs Lisp. Now, everywhere I declare a vtable filled with function pointers (and the occasional const data member), all the members of the vtable structure are initialised by name using the '.fieldname = value' syntax introduced in C99. We were already using this syntax for a handful of things in the new key-generation progress report system, so it's not new to the code base as a whole. The advantage is that now, when a vtable only declares a subset of the available fields, I can initialise the rest to NULL or zero just by leaving them out. This is most dramatic in a couple of the outlying vtables in things like psocks (which has a ConnectionLayerVtable containing only one non-NULL method), but less dramatically, it means that the new 'flags' field in BackendVtable can be completely left out of every backend definition except for the SUPDUP one which defines it to a nonzero value. Similarly, the test_for_upstream method only used by SSH doesn't have to be mentioned in the rest of the backends; network Plugs for listening sockets don't have to explicitly null out 'receive' and 'sent', and vice versa for 'accepting', and so on. While I'm at it, I've normalised the declarations so they don't use the unnecessarily verbose 'struct' keyword. Also a handful of them weren't const; now they are.
2020-03-10 21:06:29 +00:00
.add_linear = cmdgen_progress_add_linear,
.add_probabilistic = cmdgen_progress_add_probabilistic,
.ready = null_progress_ready,
.start_phase = cmdgen_progress_start_phase,
.report = cmdgen_progress_report,
.report_attempt = cmdgen_progress_report_attempt,
.report_phase_complete = cmdgen_progress_report_phase_complete,
New vtable API for keygen progress reporting. The old API was one of those horrible things I used to do when I was young and foolish, in which you have just one function, and indicate which of lots of things it's doing by passing in flags. It was crying out to be replaced with a vtable. While I'm at it, I've reworked the code on the Windows side that decides what to do with the progress bar, so that it's based on actually justifiable estimates of probability rather than magic integer constants. Since computers are generally faster now than they were at the start of this project, I've also decided there's no longer any point in making the fixed final part of RSA key generation bother to report progress at all. So the progress bars are now only for the variable part, i.e. the actual prime generations. (This is a reapplication of commit a7bdefb39, without the Miller-Rabin refactoring accidentally folded into it. Also this time I've added -lm to the link options, which for some reason _didn't_ cause me a link failure last time round. No idea why not.)
2020-02-23 15:29:40 +00:00
};
static ProgressReceiver cmdgen_progress = { .vt = &cmdgen_progress_vt };
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
/*
* Stubs to let everything else link sensibly.
*/
char *x_get_default(const char *key)
{
return NULL;
}
void sk_cleanup(void)
{
}
void showversion(void)
{
Include 'build info' in all --version text and About boxes. This shows the build platform (32- vs 64-bit in particular, and also whether Unix GTK builds were compiled with or without the X11 pieces), what compiler was used to build the binary, and any interesting build options that might have been set on the make command line (especially, but not limited to, the security-damaging ones like NO_SECURITY or UNPROTECT). This will probably be useful all over the place, but in particular it should allow the different Windows binaries to be told apart! Commits 21101c739 and 2eb952ca3 laid the groundwork for this, by allowing the various About boxes to contain free text and also ensuring they could be copied and pasted easily as part of a bug report.
2017-01-21 14:55:53 +00:00
char *buildinfo_text = buildinfo("\n");
Unix 'puttygen --help' was a mess. Bring it into line with the other PuTTY tools: --help goes to stdout, has a one-line purpose and brief version information, --version ends with a newline. (Also, tweak text bring the help message under 80 columns.)
2017-02-11 20:12:55 +00:00
printf("puttygen: %s\n%s\n", ver, buildinfo_text);
Include 'build info' in all --version text and About boxes. This shows the build platform (32- vs 64-bit in particular, and also whether Unix GTK builds were compiled with or without the X11 pieces), what compiler was used to build the binary, and any interesting build options that might have been set on the make command line (especially, but not limited to, the security-damaging ones like NO_SECURITY or UNPROTECT). This will probably be useful all over the place, but in particular it should allow the different Windows binaries to be told apart! Commits 21101c739 and 2eb952ca3 laid the groundwork for this, by allowing the various About boxes to contain free text and also ensuring they could be copied and pasted easily as part of a bug report.
2017-01-21 14:55:53 +00:00
sfree(buildinfo_text);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
void usage(bool standalone)
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
{
Unix 'puttygen --help' was a mess. Bring it into line with the other PuTTY tools: --help goes to stdout, has a one-line purpose and brief version information, --version ends with a newline. (Also, tweak text bring the help message under 80 columns.)
2017-02-11 20:12:55 +00:00
fprintf(standalone ? stderr : stdout,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"Usage: puttygen ( keyfile | -t type [ -b bits ] )\n"
" [ -C comment ] [ -P ] [ -q ]\n"
" [ -o output-keyfile ] [ -O type | -l | -L"
" | -p ]\n");
When Unix PuTTYgen gives brief usage information, it should mention "--help"! [originally from svn r6732]
2006-06-17 13:01:04 +00:00
if (standalone)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fprintf(stderr,
"Use \"puttygen --help\" for more detail.\n");
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
void help(void)
{
/*
* Help message is an extended version of the usage message. So
* start with that, plus a version heading.
*/
Unix 'puttygen --help' was a mess. Bring it into line with the other PuTTY tools: --help goes to stdout, has a one-line purpose and brief version information, --version ends with a newline. (Also, tweak text bring the help message under 80 columns.)
2017-02-11 20:12:55 +00:00
printf("PuTTYgen: key generator and converter for the PuTTY tools\n"
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"%s\n", ver);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
usage(false);
PuTTYgen: prepare for more general EdDSA. In the Windows GUI, all the controls that were previously named or labelled Ed25519 are now labelled EdDSA, and when you select that top-level key type, there's a dropdown for the specific curve (just like for ECDSA), whose only current value is Ed25519. In command-line PuTTYgen, you can say '-t eddsa' and give a number of bits, just like '-t ecdsa'. You can also still say '-t ed25519', for backwards compatibility. Also in command-line PuTTYgen, I've reworked the error messages if you give a number of bits that doesn't correspond to a known elliptic curve. Now the messages are generated by consulting the list of curves, so that that list has to be updated by hand in one fewer place.
2020-03-02 07:05:19 +00:00
printf(" -t specify key type when generating:\n"
" eddsa, ecdsa, rsa, dsa, rsa1 use with -b\n"
Support the new "ssh-ed448" key type. This is standardised by RFC 8709 at SHOULD level, and for us it's not too difficult (because we use general-purpose elliptic-curve code). So let's be up to date for a change, and add it. This implementation uses all the formats defined in the RFC. But we also have to choose a wire format for the public+private key blob sent to an agent, and since the OpenSSH agent protocol is the de facto standard but not (yet?) handled by the IETF, OpenSSH themselves get to say what the format for a key should or shouldn't be. So if they don't support a particular key method, what do you do? I checked with them, and they agreed that there's an obviously right format for Ed448 keys, which is to do them exactly like Ed25519 except that you have a 57-byte string everywhere Ed25519 had a 32-byte string. So I've done that.
2020-03-02 07:09:08 +00:00
" ed25519, ed448 special cases of eddsa\n"
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
" -b specify number of bits when generating key\n"
" -C change or specify key comment\n"
" -P change key passphrase\n"
" -q quiet: do not display progress bar\n"
" -O specify output type:\n"
" private output PuTTY private key format\n"
" private-openssh export OpenSSH private key\n"
" private-openssh-new export OpenSSH private key "
Unix 'puttygen --help' was a mess. Bring it into line with the other PuTTY tools: --help goes to stdout, has a one-line purpose and brief version information, --version ends with a newline. (Also, tweak text bring the help message under 80 columns.)
2017-02-11 20:12:55 +00:00
"(force new format)\n"
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
" private-sshcom export ssh.com private key\n"
" public RFC 4716 / ssh.com public key\n"
" public-openssh OpenSSH public key\n"
" fingerprint output the key fingerprint\n"
cmdgen: add a --dump option. Also spelled '-O text', this takes a public or private key as input, and produces on standard output a dump of all the actual numbers involved in the key: the exponent and modulus for RSA, the p,q,g,y parameters for DSA, the affine x and y coordinates of the public elliptic curve point for ECC keys, and all the extra bits and pieces in the private keys too. Partly I expect this to be useful to me for debugging: I've had to paste key files a few too many times through base64 decoders and hex dump tools, then manually decode SSH marshalling and paste the result into the Python REPL to get an integer object. Now I should be able to get _straight_ to text I can paste into Python. But also, it's a way that other applications can use the key generator: if you need to generate, say, an RSA key in some format I don't support (I've recently heard of an XML-based one, for example), then you can run 'puttygen -t rsa --dump' and have it print the elements of a freshly generated keypair on standard output, and then all you have to do is understand the output format.
2020-02-17 19:53:19 +00:00
" text output the key components as "
"'name=0x####'\n"
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
" -o specify output file\n"
" -l equivalent to `-O fingerprint'\n"
" -L equivalent to `-O public-openssh'\n"
" -p equivalent to `-O public'\n"
cmdgen: document --dump in the online help. There's always something.
2020-02-23 12:02:19 +00:00
" --dump equivalent to `-O text'\n"
cmdgen: add a --reencrypt option. This allows you to load and save the same key without making any semantic changes to it. Currently, you can only do that by pretending to make a change, like changing the passphrase or the comment to the same thing it was before. With two key file formats now supported, and a bunch of reconfigurable parameters in the v3 key derivation, it's now more likely that you'd want to re-encrypt the same key in a different way, to upgrade or downgrade or tinker with it. (Or perhaps even just re-randomise the salt, so that someone reading the key file doesn't know _whether_ you've changed the passphrase!)
2021-02-22 17:56:02 +00:00
" --reencrypt load a key and save it with fresh "
"encryption\n"
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
" --old-passphrase file\n"
" specify file containing old key passphrase\n"
" --new-passphrase file\n"
" specify file containing new key passphrase\n"
" --random-device device\n"
" specify device to read entropy from (e.g. /dev/urandom)\n"
cmdgen: add help for the --primes option. There's always something. I added the actual option, but forgot to advertise it in the online help. While I'm here, I've also allowed the word 'proven' as an alternative spelling for 'provable', because having the approved spellings be 'probable' and 'provable' is just asking for hilarious typos.
2020-03-01 20:37:09 +00:00
" --primes <type> select prime-generation method:\n"
" probable conventional probabilistic prime finding\n"
" proven numbers that have been proven to be prime\n"
" proven-even also try harder for an even distribution\n"
RSA generation: option to generate strong primes. A 'strong' prime, as defined by the Handbook of Applied Cryptography, is a prime p such that each of p-1 and p+1 has a large prime factor, and that the large factor q of p-1 is such that q-1 in turn _also_ has a large prime factor. HoAC says that making your RSA key using primes of this form defeats some factoring algorithms - but there are other faster algorithms to which it makes no difference. So this is probably not a useful precaution in practice. However, it has been recommended in the past by some official standards, and it's easy to implement given the new general facility in PrimeCandidateSource that lets you ask for your prime to satisfy an arbitrary modular congruence. (And HoAC also says there's no particular reason _not_ to use strong primes.) So I provide it as an option, just in case anyone wants to select it. The change to the key generation algorithm is entirely in sshrsag.c, and is neatly independent of the prime-generation system in use. If you're using Maurer provable prime generation, then the known factor q of p-1 can be used to help certify p, and the one for q-1 to help with q in turn; if you switch to probabilistic prime generation then you still get an RSA key with the right structure, except that every time the definition says 'prime factor' you just append '(probably)'. (The probabilistic version of this procedure is described as 'Gordon's algorithm' in HoAC section 4.4.2.)
2020-03-02 06:52:09 +00:00
" --strong-rsa use \"strong\" primes as RSA key factors\n"
cmdgen: command-line control of PPK save parameters. This allows you to manually adjust the Argon2 parameters so that you can trade off CPU requirements in legitimate use against difficulty of brute-force attack. It also allows downgrading the key file version back to the widespread PPK v2, so you can manually back-port a key that you accidentally generated too new.
2021-02-22 18:13:12 +00:00
" --ppk-param <key>=<value>[,<key>=<value>,...]\n"
" specify parameters when writing PuTTY private key file "
"format:\n"
" version PPK format version (min 2, max 3, "
"default 3)\n"
PuTTYgen: option to control Argon2 flavour. I left this out of yesterday's collection of cmdgen CLI options and GUI PuTTYgen dialog box, but only because I forgot about it. I don't know off the top of my head why someone would particularly want to configure this detail, but given that it _is_ configurable, it seems like no extra trouble to expose it along with the rest of the parameters, just in case.
2021-02-23 18:26:50 +00:00
" kdf key derivation function (argon2id, "
"argon2i, argon2d)\n"
PuTTYgen: use the term "passphrase hash". PuTTYgen and its documentation are pretty consistent about calling their encryption key a 'passphrase', as opposed to a 'password' supplied directly to a server; but the Argon2 parameters UI reverted to 'password hash', which seemed unecessarily confusing. I think it's better to use the term 'passphrase' consistently in the UI. (People who are used to Argon2 being called a 'password hash' can probably deal.) This required tweaking the coordinates of the Windows PuTTYgen UI.
2021-04-19 16:55:50 +00:00
" memory Kbyte of memory to use in passphrase "
"hash\n"
" (default 8192)\n"
cmdgen: command-line control of PPK save parameters. This allows you to manually adjust the Argon2 parameters so that you can trade off CPU requirements in legitimate use against difficulty of brute-force attack. It also allows downgrading the key file version back to the widespread PPK v2, so you can manually back-port a key that you accidentally generated too new.
2021-02-22 18:13:12 +00:00
" time approx milliseconds to hash for "
"(default 100)\n"
PuTTYgen: option to control Argon2 flavour. I left this out of yesterday's collection of cmdgen CLI options and GUI PuTTYgen dialog box, but only because I forgot about it. I don't know off the top of my head why someone would particularly want to configure this detail, but given that it _is_ configurable, it seems like no extra trouble to expose it along with the rest of the parameters, just in case.
2021-02-23 18:26:50 +00:00
" passes number of hash passes to run "
cmdgen: command-line control of PPK save parameters. This allows you to manually adjust the Argon2 parameters so that you can trade off CPU requirements in legitimate use against difficulty of brute-force attack. It also allows downgrading the key file version back to the widespread PPK v2, so you can manually back-port a key that you accidentally generated too new.
2021-02-22 18:13:12 +00:00
"(alternative to 'time')\n"
" parallelism number of parallelisable threads in the "
"hash function\n"
" (default 1)\n"
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
static bool move(char *from, char *to)
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
{
int ret;
ret = rename(from, to);
if (ret) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* This OS may require us to remove the original file first.
*/
remove(to);
ret = rename(from, to);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
if (ret) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
perror("puttygen: cannot move new file on to old one");
return false;
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
Add command-line passphrase-file options to command-line PuTTYgen. Patch due to Colin Watson. Putting the passphrase in a file avoids exposing it to 'ps' which can print out every process's command line, while at the same time not being as platform-specific as the approach of providing an fd number (since cmdgen.c is in principle a potential cross-platform PuTTYgen, not just a Unix one, which is why it's not in the 'unix' directory). Of course it introduces its own risks if someone can read the file from your disk after you delete it; probably the best approach to avoiding this, if possible, is to point the option at a file on an in-memory tmpfs type file system. Or better still, use bash-style /dev/fd options such as puttygen --new-passphrase <(echo -n "my passphrase") [options] Failing that, try a secure file-wipe utility, as the man page change mentions. (And a use case not to be overlooked, of course, is the one where you actually want to generate an unprotected key - in which case, just pass /dev/null as the filename.)
2016-03-17 18:42:46 +00:00
static char *readpassphrase(const char *filename)
{
FILE *fp;
char *line;
fp = fopen(filename, "r");
if (!fp) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fprintf(stderr, "puttygen: cannot open %s: %s\n",
filename, strerror(errno));
return NULL;
Add command-line passphrase-file options to command-line PuTTYgen. Patch due to Colin Watson. Putting the passphrase in a file avoids exposing it to 'ps' which can print out every process's command line, while at the same time not being as platform-specific as the approach of providing an fd number (since cmdgen.c is in principle a potential cross-platform PuTTYgen, not just a Unix one, which is why it's not in the 'unix' directory). Of course it introduces its own risks if someone can read the file from your disk after you delete it; probably the best approach to avoiding this, if possible, is to point the option at a file on an in-memory tmpfs type file system. Or better still, use bash-style /dev/fd options such as puttygen --new-passphrase <(echo -n "my passphrase") [options] Failing that, try a secure file-wipe utility, as the man page change mentions. (And a use case not to be overlooked, of course, is the one where you actually want to generate an unprotected key - in which case, just pass /dev/null as the filename.)
2016-03-17 18:42:46 +00:00
}
line = fgetline(fp);
if (line)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
line[strcspn(line, "\r\n")] = '\0';
Add command-line passphrase-file options to command-line PuTTYgen. Patch due to Colin Watson. Putting the passphrase in a file avoids exposing it to 'ps' which can print out every process's command line, while at the same time not being as platform-specific as the approach of providing an fd number (since cmdgen.c is in principle a potential cross-platform PuTTYgen, not just a Unix one, which is why it's not in the 'unix' directory). Of course it introduces its own risks if someone can read the file from your disk after you delete it; probably the best approach to avoiding this, if possible, is to point the option at a file on an in-memory tmpfs type file system. Or better still, use bash-style /dev/fd options such as puttygen --new-passphrase <(echo -n "my passphrase") [options] Failing that, try a secure file-wipe utility, as the man page change mentions. (And a use case not to be overlooked, of course, is the one where you actually want to generate an unprotected key - in which case, just pass /dev/null as the filename.)
2016-03-17 18:42:46 +00:00
else if (ferror(fp))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fprintf(stderr, "puttygen: error reading from %s: %s\n",
filename, strerror(errno));
else /* empty file */
line = dupstr("");
Add command-line passphrase-file options to command-line PuTTYgen. Patch due to Colin Watson. Putting the passphrase in a file avoids exposing it to 'ps' which can print out every process's command line, while at the same time not being as platform-specific as the approach of providing an fd number (since cmdgen.c is in principle a potential cross-platform PuTTYgen, not just a Unix one, which is why it's not in the 'unix' directory). Of course it introduces its own risks if someone can read the file from your disk after you delete it; probably the best approach to avoiding this, if possible, is to point the option at a file on an in-memory tmpfs type file system. Or better still, use bash-style /dev/fd options such as puttygen --new-passphrase <(echo -n "my passphrase") [options] Failing that, try a secure file-wipe utility, as the man page change mentions. (And a use case not to be overlooked, of course, is the one where you actually want to generate an unprotected key - in which case, just pass /dev/null as the filename.)
2016-03-17 18:42:46 +00:00
fclose(fp);
return line;
}
Warn about short RSA/DSA keys in PuTTYgen. It's only a warning; Windows PuTTYgen puts it up as a message box, and will still generate the key if you click yes, and Unix PuTTYgen just prints the warning and gets on with generation anyway. But it might help encourage people to move away from 1024-bit keys, if they're still using them.
2016-04-02 07:00:37 +00:00
#define DEFAULT_RSADSA_BITS 2048
Unix buildinfo: stop saying 'GTK' in pure CLI utilities. Unix PSCP, PSFTP, Plink and PuTTYgen now just report their build platform as '64-bit Unix' or '32-bit Unix', without mentioning irrelevant details of what flavour of GTK the other tools in the suite might have been built against. (In particular, they now won't imply anything outright untrue if there was no GTK present at build time at all!)
2017-02-22 22:10:05 +00:00
/* For Unix in particular, but harmless if this main() is reused elsewhere */
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
const bool buildinfo_gtk_relevant = false;
Unix buildinfo: stop saying 'GTK' in pure CLI utilities. Unix PSCP, PSFTP, Plink and PuTTYgen now just report their build platform as '64-bit Unix' or '32-bit Unix', without mentioning irrelevant details of what flavour of GTK the other tools in the suite might have been built against. (In particular, they now won't imply anything outright untrue if there was no GTK present at build time at all!)
2017-02-22 22:10:05 +00:00
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
int main(int argc, char **argv)
{
char *infile = NULL;
Initialise some variables to NULL, to placate optimisers. [originally from svn r9425]
2012-03-05 18:32:27 +00:00
Filename *infilename = NULL, *outfilename = NULL;
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
LoadedFile *infile_lf = NULL;
BinarySource *infile_bs = NULL;
PuTTYgen: prepare for more general EdDSA. In the Windows GUI, all the controls that were previously named or labelled Ed25519 are now labelled EdDSA, and when you select that top-level key type, there's a dropdown for the specific curve (just like for ECDSA), whose only current value is Ed25519. In command-line PuTTYgen, you can say '-t eddsa' and give a number of bits, just like '-t ecdsa'. You can also still say '-t ed25519', for backwards compatibility. Also in command-line PuTTYgen, I've reworked the error messages if you give a number of bits that doesn't correspond to a known elliptic curve. Now the messages are generated by consulting the list of curves, so that that list has to be updated by hand in one fewer place.
2020-03-02 07:05:19 +00:00
enum { NOKEYGEN, RSA1, RSA2, DSA, ECDSA, EDDSA } keytype = NOKEYGEN;
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
char *outfile = NULL, *outfiletmp = NULL;
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 06:42:48 +00:00
enum { PRIVATE, PUBLIC, PUBLICO, FP, OPENSSH_AUTO,
cmdgen: add a --dump option. Also spelled '-O text', this takes a public or private key as input, and produces on standard output a dump of all the actual numbers involved in the key: the exponent and modulus for RSA, the p,q,g,y parameters for DSA, the affine x and y coordinates of the public elliptic curve point for ECC keys, and all the extra bits and pieces in the private keys too. Partly I expect this to be useful to me for debugging: I've had to paste key files a few too many times through base64 decoders and hex dump tools, then manually decode SSH marshalling and paste the result into the Python REPL to get an integer object. Now I should be able to get _straight_ to text I can paste into Python. But also, it's a way that other applications can use the key generator: if you need to generate, say, an RSA key in some format I don't support (I've recently heard of an XML-based one, for example), then you can run 'puttygen -t rsa --dump' and have it print the elements of a freshly generated keypair on standard output, and then all you have to do is understand the output format.
2020-02-17 19:53:19 +00:00
OPENSSH_NEW, SSHCOM, TEXT } outtype = PRIVATE;
Vary cmdgen's default key size based on key type. It's a bit silly to have 'puttygen -t ecdsa' immediately crash out because the default key size is 2048 and we don't know a 2048-bit elliptic curve.
2015-05-09 14:02:47 +00:00
int bits = -1;
cmdgen: add const on main() variable 'comment'. It's a secondary reference to existing data (namely an argv word, if anything at all), and never needs to be written through, so we should mark it const, if nothing else to catch any absent-minded attempts to free it.
2019-07-06 16:54:56 +00:00
const char *comment = NULL;
char *origcomment = NULL;
cmdgen: add a --reencrypt option. This allows you to load and save the same key without making any semantic changes to it. Currently, you can only do that by pretending to make a change, like changing the passphrase or the comment to the same thing it was before. With two key file formats now supported, and a bunch of reconfigurable parameters in the v3 key derivation, it's now more likely that you'd want to re-encrypt the same key in a different way, to upgrade or downgrade or tinker with it. (Or perhaps even just re-randomise the salt, so that someone reading the key file doesn't know _whether_ you've changed the passphrase!)
2021-02-22 17:56:02 +00:00
bool change_passphrase = false, reencrypt = false;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool errs = false, nogo = false;
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
int intype = SSH_KEYTYPE_UNOPENABLE;
int sshver = 0;
Remove a lot of pointless 'struct' keywords. This is the commit that f3295e0fb _should_ have been. Yesterday I just added some typedefs so that I didn't have to wear out my fingers typing 'struct' in new code, but what I ought to have done is to move all the typedefs into defs.h with the rest, and then go through cleaning up the legacy 'struct's all through the existing code. But I was mostly trying to concentrate on getting the test suite finished, so I just did the minimum. Now it's time to come back and do it better.
2019-01-04 06:51:44 +00:00
ssh2_userkey *ssh2key = NULL;
RSAKey *ssh1key = NULL;
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 09:59:39 +00:00
strbuf *ssh2blob = NULL;
Patch from Colin Watson intended to give a clean Unix compile with GCC 4. (Since we choose to compile with -Werror, this is particularly important.) I haven't yet checked that the resulting source actually compiles cleanly with GCC 4, hence not marking `gcc4-warnings' as fixed just yet. [originally from svn r7041]
2006-12-30 23:00:14 +00:00
char *ssh2alg = NULL;
Add command-line passphrase-file options to command-line PuTTYgen. Patch due to Colin Watson. Putting the passphrase in a file avoids exposing it to 'ps' which can print out every process's command line, while at the same time not being as platform-specific as the approach of providing an fd number (since cmdgen.c is in principle a potential cross-platform PuTTYgen, not just a Unix one, which is why it's not in the 'unix' directory). Of course it introduces its own risks if someone can read the file from your disk after you delete it; probably the best approach to avoiding this, if possible, is to point the option at a file on an in-memory tmpfs type file system. Or better still, use bash-style /dev/fd options such as puttygen --new-passphrase <(echo -n "my passphrase") [options] Failing that, try a secure file-wipe utility, as the man page change mentions. (And a use case not to be overlooked, of course, is the one where you actually want to generate an unprotected key - in which case, just pass /dev/null as the filename.)
2016-03-17 18:42:46 +00:00
char *old_passphrase = NULL, *new_passphrase = NULL;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool load_encrypted;
cmdgen: option to specify the random number device to use. E.g. you might pass '--random-device=/dev/urandom'. Mostly because I got sick of waiting for /dev/random to finish blocking while I was trying to generate throwaway keys for testing bug fixes in cmdgen itself. But it might also be useful on systems that call their random device by a different name that we haven't encountered. (Since cmdgen also reads the saved PuTTY random seed file, setting this option to /dev/zero will not render key generation deterministic. It's tempting to provide _some_ way to do that, for testing purposes and clearly marked as dangerous of course, but I think it would take more faff than this.)
2016-03-30 07:17:03 +00:00
const char *random_device = NULL;
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
int exit_status = 0;
Allow asking for provable primes in PuTTYgen. In Windows PuTTYgen, this is selected by an extra set of radio-button style menu options in the Key menu. In the command-line version, there's a new --primes=provable option. This whole system is new, so I'm not enabling it by default just yet. I may in future, though: it's running faster than I expected (in particular, a lot faster than any previous prototype of the same algorithm I attempted in standalone Python).
2020-02-29 06:43:28 +00:00
const PrimeGenerationPolicy *primegen = &primegen_probabilistic;
RSA generation: option to generate strong primes. A 'strong' prime, as defined by the Handbook of Applied Cryptography, is a prime p such that each of p-1 and p+1 has a large prime factor, and that the large factor q of p-1 is such that q-1 in turn _also_ has a large prime factor. HoAC says that making your RSA key using primes of this form defeats some factoring algorithms - but there are other faster algorithms to which it makes no difference. So this is probably not a useful precaution in practice. However, it has been recommended in the past by some official standards, and it's easy to implement given the new general facility in PrimeCandidateSource that lets you ask for your prime to satisfy an arbitrary modular congruence. (And HoAC also says there's no particular reason _not_ to use strong primes.) So I provide it as an option, just in case anyone wants to select it. The change to the key generation algorithm is entirely in sshrsag.c, and is neatly independent of the prime-generation system in use. If you're using Maurer provable prime generation, then the known factor q of p-1 can be used to help certify p, and the one for q-1 to help with q in turn; if you switch to probabilistic prime generation then you still get an RSA key with the right structure, except that every time the definition says 'prime factor' you just append '(probably)'. (The probabilistic version of this procedure is described as 'Gordon's algorithm' in HoAC section 4.4.2.)
2020-03-02 06:52:09 +00:00
bool strong_rsa = false;
cmdgen: command-line control of PPK save parameters. This allows you to manually adjust the Argon2 parameters so that you can trade off CPU requirements in legitimate use against difficulty of brute-force attack. It also allows downgrading the key file version back to the widespread PPK v2, so you can manually back-port a key that you accidentally generated too new.
2021-02-22 18:13:12 +00:00
ppk_save_parameters params = ppk_save_default_parameters;
cmdgen: support configurable key fingerprint type. I've added the -E option, similar to ssh-keygen's, and cgtest checks it against the OpenSSH version to ensure they match.
2021-03-13 09:57:02 +00:00
FingerprintType fptype = SSH_FPTYPE_DEFAULT;
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
New vtable API for keygen progress reporting. The old API was one of those horrible things I used to do when I was young and foolish, in which you have just one function, and indicate which of lots of things it's doing by passing in flags. It was crying out to be replaced with a vtable. While I'm at it, I've reworked the code on the Windows side that decides what to do with the progress bar, so that it's based on actually justifiable estimates of probability rather than magic integer constants. Since computers are generally faster now than they were at the start of this project, I've also decided there's no longer any point in making the fixed final part of RSA key generation bother to report progress at all. So the progress bars are now only for the variable part, i.e. the actual prime generations. (This is a reapplication of commit a7bdefb39, without the Miller-Rabin refactoring accidentally folded into it. Also this time I've added -lm to the link options, which for some reason _didn't_ cause me a link failure last time round. No idea why not.)
2020-02-23 15:29:40 +00:00
if (is_interactive())
progress_fp = stderr;
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
#define RETURN(status) do { exit_status = (status); goto out; } while (0)
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
/* ------------------------------------------------------------------
* Parse the command line to figure out what we've been asked to do.
*/
/*
* If run with no arguments at all, print the usage message and
* return success.
*/
if (argc <= 1) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
usage(true);
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(0);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
/*
* Parse command line arguments.
*/
while (--argc) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *p = *++argv;
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
if (p[0] == '-' && p[1]) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* An option.
*/
while (p && *++p) {
char c = *p;
switch (c) {
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
case '-': {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Long option.
*/
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
char *opt, *val;
opt = p++; /* opt will have _one_ leading - */
while (*p && *p != '=')
p++; /* find end of option */
if (*p == '=') {
*p++ = '\0';
val = p;
} else
val = NULL;
if (!strcmp(opt, "-help")) {
if (val) {
errs = true;
fprintf(stderr, "puttygen: option `-%s'"
" expects no argument\n", opt);
} else {
help();
nogo = true;
}
} else if (!strcmp(opt, "-version")) {
if (val) {
errs = true;
fprintf(stderr, "puttygen: option `-%s'"
" expects no argument\n", opt);
} else {
showversion();
nogo = true;
}
} else if (!strcmp(opt, "-pgpfp")) {
if (val) {
errs = true;
fprintf(stderr, "puttygen: option `-%s'"
" expects no argument\n", opt);
} else {
/* support --pgpfp for consistency */
pgp_fingerprints();
nogo = true;
}
} else if (!strcmp(opt, "-old-passphrase")) {
if (!val && argc > 1)
--argc, val = *++argv;
if (!val) {
errs = true;
fprintf(stderr, "puttygen: option `-%s'"
" expects an argument\n", opt);
} else {
old_passphrase = readpassphrase(val);
if (!old_passphrase)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
errs = true;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
} else if (!strcmp(opt, "-new-passphrase")) {
if (!val && argc > 1)
--argc, val = *++argv;
if (!val) {
errs = true;
fprintf(stderr, "puttygen: option `-%s'"
" expects an argument\n", opt);
} else {
new_passphrase = readpassphrase(val);
if (!new_passphrase)
errs = true;
}
} else if (!strcmp(opt, "-random-device")) {
if (!val && argc > 1)
--argc, val = *++argv;
if (!val) {
errs = true;
fprintf(stderr, "puttygen: option `-%s'"
" expects an argument\n", opt);
} else {
random_device = val;
}
cmdgen: add a --dump option. Also spelled '-O text', this takes a public or private key as input, and produces on standard output a dump of all the actual numbers involved in the key: the exponent and modulus for RSA, the p,q,g,y parameters for DSA, the affine x and y coordinates of the public elliptic curve point for ECC keys, and all the extra bits and pieces in the private keys too. Partly I expect this to be useful to me for debugging: I've had to paste key files a few too many times through base64 decoders and hex dump tools, then manually decode SSH marshalling and paste the result into the Python REPL to get an integer object. Now I should be able to get _straight_ to text I can paste into Python. But also, it's a way that other applications can use the key generator: if you need to generate, say, an RSA key in some format I don't support (I've recently heard of an XML-based one, for example), then you can run 'puttygen -t rsa --dump' and have it print the elements of a freshly generated keypair on standard output, and then all you have to do is understand the output format.
2020-02-17 19:53:19 +00:00
} else if (!strcmp(opt, "-dump")) {
outtype = TEXT;
Allow asking for provable primes in PuTTYgen. In Windows PuTTYgen, this is selected by an extra set of radio-button style menu options in the Key menu. In the command-line version, there's a new --primes=provable option. This whole system is new, so I'm not enabling it by default just yet. I may in future, though: it's running faster than I expected (in particular, a lot faster than any previous prototype of the same algorithm I attempted in standalone Python).
2020-02-29 06:43:28 +00:00
} else if (!strcmp(opt, "-primes")) {
if (!val && argc > 1)
--argc, val = *++argv;
if (!val) {
errs = true;
fprintf(stderr, "puttygen: option `-%s'"
" expects an argument\n", opt);
} else if (!strcmp(val, "probable") ||
!strcmp(val, "probabilistic")) {
primegen = &primegen_probabilistic;
} else if (!strcmp(val, "provable") ||
cmdgen: add help for the --primes option. There's always something. I added the actual option, but forgot to advertise it in the online help. While I'm here, I've also allowed the word 'proven' as an alternative spelling for 'provable', because having the approved spellings be 'probable' and 'provable' is just asking for hilarious typos.
2020-03-01 20:37:09 +00:00
!strcmp(val, "proven") ||
Allow asking for provable primes in PuTTYgen. In Windows PuTTYgen, this is selected by an extra set of radio-button style menu options in the Key menu. In the command-line version, there's a new --primes=provable option. This whole system is new, so I'm not enabling it by default just yet. I may in future, though: it's running faster than I expected (in particular, a lot faster than any previous prototype of the same algorithm I attempted in standalone Python).
2020-02-29 06:43:28 +00:00
!strcmp(val, "simple") ||
!strcmp(val, "maurer-simple")) {
primegen = &primegen_provable_maurer_simple;
} else if (!strcmp(val, "provable-even") ||
cmdgen: add help for the --primes option. There's always something. I added the actual option, but forgot to advertise it in the online help. While I'm here, I've also allowed the word 'proven' as an alternative spelling for 'provable', because having the approved spellings be 'probable' and 'provable' is just asking for hilarious typos.
2020-03-01 20:37:09 +00:00
!strcmp(val, "proven-even") ||
Allow asking for provable primes in PuTTYgen. In Windows PuTTYgen, this is selected by an extra set of radio-button style menu options in the Key menu. In the command-line version, there's a new --primes=provable option. This whole system is new, so I'm not enabling it by default just yet. I may in future, though: it's running faster than I expected (in particular, a lot faster than any previous prototype of the same algorithm I attempted in standalone Python).
2020-02-29 06:43:28 +00:00
!strcmp(val, "even") ||
!strcmp(val, "complex") ||
!strcmp(val, "maurer-complex")) {
primegen = &primegen_provable_maurer_complex;
} else {
errs = true;
fprintf(stderr, "puttygen: unrecognised prime-"
"generation mode `%s'\n", val);
}
RSA generation: option to generate strong primes. A 'strong' prime, as defined by the Handbook of Applied Cryptography, is a prime p such that each of p-1 and p+1 has a large prime factor, and that the large factor q of p-1 is such that q-1 in turn _also_ has a large prime factor. HoAC says that making your RSA key using primes of this form defeats some factoring algorithms - but there are other faster algorithms to which it makes no difference. So this is probably not a useful precaution in practice. However, it has been recommended in the past by some official standards, and it's easy to implement given the new general facility in PrimeCandidateSource that lets you ask for your prime to satisfy an arbitrary modular congruence. (And HoAC also says there's no particular reason _not_ to use strong primes.) So I provide it as an option, just in case anyone wants to select it. The change to the key generation algorithm is entirely in sshrsag.c, and is neatly independent of the prime-generation system in use. If you're using Maurer provable prime generation, then the known factor q of p-1 can be used to help certify p, and the one for q-1 to help with q in turn; if you switch to probabilistic prime generation then you still get an RSA key with the right structure, except that every time the definition says 'prime factor' you just append '(probably)'. (The probabilistic version of this procedure is described as 'Gordon's algorithm' in HoAC section 4.4.2.)
2020-03-02 06:52:09 +00:00
} else if (!strcmp(opt, "-strong-rsa")) {
strong_rsa = true;
cmdgen: add a --reencrypt option. This allows you to load and save the same key without making any semantic changes to it. Currently, you can only do that by pretending to make a change, like changing the passphrase or the comment to the same thing it was before. With two key file formats now supported, and a bunch of reconfigurable parameters in the v3 key derivation, it's now more likely that you'd want to re-encrypt the same key in a different way, to upgrade or downgrade or tinker with it. (Or perhaps even just re-randomise the salt, so that someone reading the key file doesn't know _whether_ you've changed the passphrase!)
2021-02-22 17:56:02 +00:00
} else if (!strcmp(opt, "-reencrypt")) {
reencrypt = true;
cmdgen: command-line control of PPK save parameters. This allows you to manually adjust the Argon2 parameters so that you can trade off CPU requirements in legitimate use against difficulty of brute-force attack. It also allows downgrading the key file version back to the widespread PPK v2, so you can manually back-port a key that you accidentally generated too new.
2021-02-22 18:13:12 +00:00
} else if (!strcmp(opt, "-ppk-param") ||
!strcmp(opt, "-ppk-params")) {
if (!val && argc > 1)
--argc, val = *++argv;
if (!val) {
errs = true;
fprintf(stderr, "puttygen: option `-%s'"
" expects an argument\n", opt);
} else {
char *nextval;
for (; val; val = nextval) {
nextval = strchr(val, ',');
if (nextval)
*nextval++ = '\0';
char *optvalue = strchr(val, '=');
if (!optvalue) {
errs = true;
fprintf(stderr, "puttygen: PPK parameter "
"'%s' expected a value\n", val);
continue;
}
*optvalue++ = '\0';
PuTTYgen: option to control Argon2 flavour. I left this out of yesterday's collection of cmdgen CLI options and GUI PuTTYgen dialog box, but only because I forgot about it. I don't know off the top of my head why someone would particularly want to configure this detail, but given that it _is_ configurable, it seems like no extra trouble to expose it along with the rest of the parameters, just in case.
2021-02-23 18:26:50 +00:00
/* Non-numeric options */
if (!strcmp(val, "kdf")) {
if (!strcmp(optvalue, "Argon2id") ||
!strcmp(optvalue, "argon2id")) {
params.argon2_flavour = Argon2id;
} else if (!strcmp(optvalue, "Argon2i") ||
!strcmp(optvalue, "argon2i")) {
params.argon2_flavour = Argon2i;
} else if (!strcmp(optvalue, "Argon2d") ||
!strcmp(optvalue, "argon2d")) {
params.argon2_flavour = Argon2d;
} else {
errs = true;
fprintf(stderr, "puttygen: unrecognise"
"d kdf '%s'\n", optvalue);
}
continue;
}
cmdgen: command-line control of PPK save parameters. This allows you to manually adjust the Argon2 parameters so that you can trade off CPU requirements in legitimate use against difficulty of brute-force attack. It also allows downgrading the key file version back to the widespread PPK v2, so you can manually back-port a key that you accidentally generated too new.
2021-02-22 18:13:12 +00:00
char *end;
unsigned long n = strtoul(optvalue, &end, 0);
if (!*optvalue || *end) {
errs = true;
fprintf(stderr, "puttygen: value '%s' for "
"PPK parameter '%s': expected a "
"number\n", optvalue, val);
continue;
}
if (!strcmp(val, "version")) {
params.fmt_version = n;
} else if (!strcmp(val, "memory") ||
!strcmp(val, "mem")) {
params.argon2_mem = n;
} else if (!strcmp(val, "time")) {
params.argon2_passes_auto = true;
params.argon2_milliseconds = n;
} else if (!strcmp(val, "passes")) {
params.argon2_passes_auto = false;
params.argon2_milliseconds = n;
} else if (!strcmp(val, "parallelism") ||
!strcmp(val, "parallel")) {
params.argon2_parallelism = n;
} else {
errs = true;
fprintf(stderr, "puttygen: unrecognised "
"PPK parameter '%s'\n", val);
continue;
}
}
}
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
} else {
errs = true;
fprintf(stderr,
"puttygen: no such option `-%s'\n", opt);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
p = NULL;
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
case 'h':
case 'V':
case 'P':
case 'l':
case 'L':
case 'p':
case 'q':
/*
* Option requiring no parameter.
*/
switch (c) {
case 'h':
help();
nogo = true;
break;
case 'V':
showversion();
nogo = true;
break;
case 'P':
change_passphrase = true;
break;
case 'l':
outtype = FP;
break;
case 'L':
outtype = PUBLICO;
break;
case 'p':
outtype = PUBLIC;
break;
case 'q':
New vtable API for keygen progress reporting. The old API was one of those horrible things I used to do when I was young and foolish, in which you have just one function, and indicate which of lots of things it's doing by passing in flags. It was crying out to be replaced with a vtable. While I'm at it, I've reworked the code on the Windows side that decides what to do with the progress bar, so that it's based on actually justifiable estimates of probability rather than magic integer constants. Since computers are generally faster now than they were at the start of this project, I've also decided there's no longer any point in making the fixed final part of RSA key generation bother to report progress at all. So the progress bars are now only for the variable part, i.e. the actual prime generations. (This is a reapplication of commit a7bdefb39, without the Miller-Rabin refactoring accidentally folded into it. Also this time I've added -lm to the link options, which for some reason _didn't_ cause me a link failure last time round. No idea why not.)
2020-02-23 15:29:40 +00:00
progress_fp = NULL;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
}
break;
case 't':
case 'b':
case 'C':
case 'O':
case 'o':
cmdgen: support configurable key fingerprint type. I've added the -E option, similar to ssh-keygen's, and cgtest checks it against the OpenSSH version to ensure they match.
2021-03-13 09:57:02 +00:00
case 'E':
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* Option requiring parameter.
*/
p++;
if (!*p && argc > 1)
--argc, p = *++argv;
else if (!*p) {
fprintf(stderr, "puttygen: option `-%c' expects a"
" parameter\n", c);
errs = true;
}
/*
* Now c is the option and p is the parameter.
*/
switch (c) {
case 't':
if (!strcmp(p, "rsa") || !strcmp(p, "rsa2"))
keytype = RSA2, sshver = 2;
else if (!strcmp(p, "rsa1"))
keytype = RSA1, sshver = 1;
else if (!strcmp(p, "dsa") || !strcmp(p, "dss"))
keytype = DSA, sshver = 2;
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 09:45:20 +00:00
else if (!strcmp(p, "ecdsa"))
keytype = ECDSA, sshver = 2;
PuTTYgen: prepare for more general EdDSA. In the Windows GUI, all the controls that were previously named or labelled Ed25519 are now labelled EdDSA, and when you select that top-level key type, there's a dropdown for the specific curve (just like for ECDSA), whose only current value is Ed25519. In command-line PuTTYgen, you can say '-t eddsa' and give a number of bits, just like '-t ecdsa'. You can also still say '-t ed25519', for backwards compatibility. Also in command-line PuTTYgen, I've reworked the error messages if you give a number of bits that doesn't correspond to a known elliptic curve. Now the messages are generated by consulting the list of curves, so that that list has to be updated by hand in one fewer place.
2020-03-02 07:05:19 +00:00
else if (!strcmp(p, "eddsa"))
keytype = EDDSA, sshver = 2;
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 14:02:54 +00:00
else if (!strcmp(p, "ed25519"))
PuTTYgen: prepare for more general EdDSA. In the Windows GUI, all the controls that were previously named or labelled Ed25519 are now labelled EdDSA, and when you select that top-level key type, there's a dropdown for the specific curve (just like for ECDSA), whose only current value is Ed25519. In command-line PuTTYgen, you can say '-t eddsa' and give a number of bits, just like '-t ecdsa'. You can also still say '-t ed25519', for backwards compatibility. Also in command-line PuTTYgen, I've reworked the error messages if you give a number of bits that doesn't correspond to a known elliptic curve. Now the messages are generated by consulting the list of curves, so that that list has to be updated by hand in one fewer place.
2020-03-02 07:05:19 +00:00
keytype = EDDSA, bits = 255, sshver = 2;
Support the new "ssh-ed448" key type. This is standardised by RFC 8709 at SHOULD level, and for us it's not too difficult (because we use general-purpose elliptic-curve code). So let's be up to date for a change, and add it. This implementation uses all the formats defined in the RFC. But we also have to choose a wire format for the public+private key blob sent to an agent, and since the OpenSSH agent protocol is the de facto standard but not (yet?) handled by the IETF, OpenSSH themselves get to say what the format for a key should or shouldn't be. So if they don't support a particular key method, what do you do? I checked with them, and they agreed that there's an obviously right format for Ed448 keys, which is to do them exactly like Ed25519 except that you have a 57-byte string everywhere Ed25519 had a 32-byte string. So I've done that.
2020-03-02 07:09:08 +00:00
else if (!strcmp(p, "ed448"))
keytype = EDDSA, bits = 448, sshver = 2;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
else {
fprintf(stderr,
"puttygen: unknown key type `%s'\n", p);
errs = true;
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
break;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
case 'b':
bits = atoi(p);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
break;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
case 'C':
comment = p;
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
break;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
case 'O':
if (!strcmp(p, "public"))
outtype = PUBLIC;
else if (!strcmp(p, "public-openssh"))
outtype = PUBLICO;
else if (!strcmp(p, "private"))
outtype = PRIVATE;
else if (!strcmp(p, "fingerprint"))
outtype = FP;
else if (!strcmp(p, "private-openssh"))
outtype = OPENSSH_AUTO, sshver = 2;
else if (!strcmp(p, "private-openssh-new"))
outtype = OPENSSH_NEW, sshver = 2;
else if (!strcmp(p, "private-sshcom"))
outtype = SSHCOM, sshver = 2;
cmdgen: add a --dump option. Also spelled '-O text', this takes a public or private key as input, and produces on standard output a dump of all the actual numbers involved in the key: the exponent and modulus for RSA, the p,q,g,y parameters for DSA, the affine x and y coordinates of the public elliptic curve point for ECC keys, and all the extra bits and pieces in the private keys too. Partly I expect this to be useful to me for debugging: I've had to paste key files a few too many times through base64 decoders and hex dump tools, then manually decode SSH marshalling and paste the result into the Python REPL to get an integer object. Now I should be able to get _straight_ to text I can paste into Python. But also, it's a way that other applications can use the key generator: if you need to generate, say, an RSA key in some format I don't support (I've recently heard of an XML-based one, for example), then you can run 'puttygen -t rsa --dump' and have it print the elements of a freshly generated keypair on standard output, and then all you have to do is understand the output format.
2020-02-17 19:53:19 +00:00
else if (!strcmp(p, "text"))
outtype = TEXT;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
else {
fprintf(stderr,
"puttygen: unknown output type `%s'\n", p);
errs = true;
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
break;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
case 'o':
outfile = p;
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
break;
cmdgen: support configurable key fingerprint type. I've added the -E option, similar to ssh-keygen's, and cgtest checks it against the OpenSSH version to ensure they match.
2021-03-13 09:57:02 +00:00
case 'E':
if (!strcmp(p, "md5"))
fptype = SSH_FPTYPE_MD5;
else if (!strcmp(p, "sha256"))
fptype = SSH_FPTYPE_SHA256;
else {
fprintf(stderr, "puttygen: unknown fingerprint "
"type `%s'\n", p);
errs = true;
}
break;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
p = NULL; /* prevent continued processing */
break;
default:
/*
* Unrecognised option.
*/
errs = true;
fprintf(stderr, "puttygen: no such option `-%c'\n", c);
break;
}
}
} else {
/*
* A non-option argument.
*/
if (!infile)
infile = p;
else {
errs = true;
fprintf(stderr, "puttygen: cannot handle more than one"
" input file\n");
}
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
Vary cmdgen's default key size based on key type. It's a bit silly to have 'puttygen -t ecdsa' immediately crash out because the default key size is 2048 and we don't know a 2048-bit elliptic curve.
2015-05-09 14:02:47 +00:00
if (bits == -1) {
/*
* No explicit key size was specified. Default varies
* depending on key type.
*/
switch (keytype) {
case ECDSA:
bits = 384;
break;
PuTTYgen: prepare for more general EdDSA. In the Windows GUI, all the controls that were previously named or labelled Ed25519 are now labelled EdDSA, and when you select that top-level key type, there's a dropdown for the specific curve (just like for ECDSA), whose only current value is Ed25519. In command-line PuTTYgen, you can say '-t eddsa' and give a number of bits, just like '-t ecdsa'. You can also still say '-t ed25519', for backwards compatibility. Also in command-line PuTTYgen, I've reworked the error messages if you give a number of bits that doesn't correspond to a known elliptic curve. Now the messages are generated by consulting the list of curves, so that that list has to be updated by hand in one fewer place.
2020-03-02 07:05:19 +00:00
case EDDSA:
PuTTYgen: permit and prefer 255 as bit count for ed25519. In setting up the ECC tests for cmdgen, I noticed that OpenSSH and PuTTYgen disagree on the bit length to put in a key fingerprint for an ed25519 key: we think 255, they think 256. On reflection, I think 255 is more accurate, which is why I bodged get_fp() in the test suite to ignore that difference when checking our key fingerprint against OpenSSH's. But having done that, it now seems silly that if you unnecessarily specify a bit count at ed25519 generation time, cmdgen will insist that it be 256! 255 is now permitted everywhere an ed25519 bit count is input. 256 is also still allowed for backwards compatibility but 255 is preferred by the error message if you give any other value.
2020-01-14 06:39:32 +00:00
bits = 255;
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 14:02:54 +00:00
break;
Vary cmdgen's default key size based on key type. It's a bit silly to have 'puttygen -t ecdsa' immediately crash out because the default key size is 2048 and we don't know a 2048-bit elliptic curve.
2015-05-09 14:02:47 +00:00
default:
Warn about short RSA/DSA keys in PuTTYgen. It's only a warning; Windows PuTTYgen puts it up as a message box, and will still generate the key if you click yes, and Unix PuTTYgen just prints the warning and gets on with generation anyway. But it might help encourage people to move away from 1024-bit keys, if they're still using them.
2016-04-02 07:00:37 +00:00
bits = DEFAULT_RSADSA_BITS;
Vary cmdgen's default key size based on key type. It's a bit silly to have 'puttygen -t ecdsa' immediately crash out because the default key size is 2048 and we don't know a 2048-bit elliptic curve.
2015-05-09 14:02:47 +00:00
break;
}
}
PuTTYgen: prepare for more general EdDSA. In the Windows GUI, all the controls that were previously named or labelled Ed25519 are now labelled EdDSA, and when you select that top-level key type, there's a dropdown for the specific curve (just like for ECDSA), whose only current value is Ed25519. In command-line PuTTYgen, you can say '-t eddsa' and give a number of bits, just like '-t ecdsa'. You can also still say '-t ed25519', for backwards compatibility. Also in command-line PuTTYgen, I've reworked the error messages if you give a number of bits that doesn't correspond to a known elliptic curve. Now the messages are generated by consulting the list of curves, so that that list has to be updated by hand in one fewer place.
2020-03-02 07:05:19 +00:00
if (keytype == ECDSA || keytype == EDDSA) {
const char *name = (keytype == ECDSA ? "ECDSA" : "EdDSA");
const int *valid_lengths = (keytype == ECDSA ? ec_nist_curve_lengths :
ec_ed_curve_lengths);
size_t n_lengths = (keytype == ECDSA ? n_ec_nist_curve_lengths :
n_ec_ed_curve_lengths);
bool (*alg_and_curve_by_bits)(int, const struct ec_curve **,
const ssh_keyalg **) =
(keytype == ECDSA ? ec_nist_alg_and_curve_by_bits :
ec_ed_alg_and_curve_by_bits);
const struct ec_curve *curve;
const ssh_keyalg *alg;
if (!alg_and_curve_by_bits(bits, &curve, &alg)) {
fprintf(stderr, "puttygen: invalid bits for %s, choose", name);
for (size_t i = 0; i < n_lengths; i++)
fprintf(stderr, "%s%d", (i == 0 ? " " :
i == n_lengths-1 ? " or " : ", "),
valid_lengths[i]);
fputc('\n', stderr);
errs = true;
}
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 14:02:54 +00:00
}
cmdgen: refuse to generate RSA/DSA keys under 256 bits. This replicates the existing error message in Windows PuTTYgen, on the basis that keys smaller than that will actually fail to work with our signing code.
2016-03-30 10:41:11 +00:00
if (keytype == RSA2 || keytype == RSA1 || keytype == DSA) {
if (bits < 256) {
fprintf(stderr, "puttygen: cannot generate %s keys shorter than"
" 256 bits\n", (keytype == DSA ? "DSA" : "RSA"));
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
errs = true;
Warn about short RSA/DSA keys in PuTTYgen. It's only a warning; Windows PuTTYgen puts it up as a message box, and will still generate the key if you click yes, and Unix PuTTYgen just prints the warning and gets on with generation anyway. But it might help encourage people to move away from 1024-bit keys, if they're still using them.
2016-04-02 07:00:37 +00:00
} else if (bits < DEFAULT_RSADSA_BITS) {
fprintf(stderr, "puttygen: warning: %s keys shorter than"
" %d bits are probably not secure\n",
(keytype == DSA ? "DSA" : "RSA"), DEFAULT_RSADSA_BITS);
/* but this is just a warning, so proceed anyway */
cmdgen: refuse to generate RSA/DSA keys under 256 bits. This replicates the existing error message in Windows PuTTYgen, on the basis that keys smaller than that will actually fail to work with our signing code.
2016-03-30 10:41:11 +00:00
}
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
if (errs)
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
if (nogo)
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(0);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
/*
* If run with at least one argument _but_ not the required
* ones, print the usage message and return failure.
*/
if (!infile && keytype == NOKEYGEN) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
usage(true);
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
/* ------------------------------------------------------------------
* Figure out further details of exactly what we're going to do.
*/
/*
* Bomb out if we've been asked to both load and generate a
* key.
*/
Random Unix puttygen improvements highlighted by a post to comp.security.ssh: - fix diagnostic if keyfile and '-t' both specified - add diagnostic for generating a key but discarding the private part - document '-q' option [originally from svn r6750]
2006-07-07 14:18:47 +00:00
if (keytype != NOKEYGEN && infile) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fprintf(stderr, "puttygen: cannot both load and generate a key\n");
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
Random Unix puttygen improvements highlighted by a post to comp.security.ssh: - fix diagnostic if keyfile and '-t' both specified - add diagnostic for generating a key but discarding the private part - document '-q' option [originally from svn r6750]
2006-07-07 14:18:47 +00:00
* We must save the private part when generating a new key.
*/
if (keytype != NOKEYGEN &&
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(outtype != PRIVATE && outtype != OPENSSH_AUTO &&
cmdgen: add a --dump option. Also spelled '-O text', this takes a public or private key as input, and produces on standard output a dump of all the actual numbers involved in the key: the exponent and modulus for RSA, the p,q,g,y parameters for DSA, the affine x and y coordinates of the public elliptic curve point for ECC keys, and all the extra bits and pieces in the private keys too. Partly I expect this to be useful to me for debugging: I've had to paste key files a few too many times through base64 decoders and hex dump tools, then manually decode SSH marshalling and paste the result into the Python REPL to get an integer object. Now I should be able to get _straight_ to text I can paste into Python. But also, it's a way that other applications can use the key generator: if you need to generate, say, an RSA key in some format I don't support (I've recently heard of an XML-based one, for example), then you can run 'puttygen -t rsa --dump' and have it print the elements of a freshly generated keypair on standard output, and then all you have to do is understand the output format.
2020-02-17 19:53:19 +00:00
outtype != OPENSSH_NEW && outtype != SSHCOM && outtype != TEXT)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fprintf(stderr, "puttygen: this would generate a new key but "
"discard the private part\n");
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Random Unix puttygen improvements highlighted by a post to comp.security.ssh: - fix diagnostic if keyfile and '-t' both specified - add diagnostic for generating a key but discarding the private part - document '-q' option [originally from svn r6750]
2006-07-07 14:18:47 +00:00
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
/*
* Analyse the type of the input file, in case this affects our
* course of action.
*/
if (infile) {
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
const char *load_error;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
infilename = filename_from_str(infile);
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
if (!strcmp(infile, "-"))
infile_lf = lf_load_keyfile_fp(stdin, &load_error);
else
infile_lf = lf_load_keyfile(infilename, &load_error);
if (!infile_lf) {
fprintf(stderr, "puttygen: unable to load file `%s': %s\n",
infile, load_error);
RETURN(1);
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
infile_bs = BinarySource_UPCAST(infile_lf);
intype = key_type_s(infile_bs);
BinarySource_REWIND(infile_bs);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
switch (intype) {
case SSH_KEYTYPE_UNOPENABLE:
case SSH_KEYTYPE_UNKNOWN:
fprintf(stderr, "puttygen: unable to load file `%s': %s\n",
infile, key_type_to_str(intype));
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
case SSH_KEYTYPE_SSH1:
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 11:19:57 +00:00
case SSH_KEYTYPE_SSH1_PUBLIC:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (sshver == 2) {
fprintf(stderr, "puttygen: conversion from SSH-1 to SSH-2 keys"
" not supported\n");
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
sshver = 1;
break;
case SSH_KEYTYPE_SSH2:
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 11:19:57 +00:00
case SSH_KEYTYPE_SSH2_PUBLIC_RFC4716:
case SSH_KEYTYPE_SSH2_PUBLIC_OPENSSH:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
case SSH_KEYTYPE_OPENSSH_PEM:
case SSH_KEYTYPE_OPENSSH_NEW:
case SSH_KEYTYPE_SSHCOM:
if (sshver == 1) {
fprintf(stderr, "puttygen: conversion from SSH-2 to SSH-1 keys"
" not supported\n");
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
sshver = 2;
break;
case SSH_KEYTYPE_OPENSSH_AUTO:
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 06:42:48 +00:00
default:
Replace assert(false) with an unreachable() macro. Taking a leaf out of the LLVM code base: this macro still includes an assert(false) so that the message will show up in a typical build, but it follows it up with a call to a function explicitly marked as no- return. So this ought to do a better job of convincing compilers that once a code path hits this function it _really doesn't_ have to still faff about with making up a bogus return value or filling in a variable that 'might be used uninitialised' in the following code that won't be reached anyway. I've gone through the existing code looking for the assert(false) / assert(0) idiom and replaced all the ones I found with the new macro, which also meant I could remove a few pointless return statements and variable initialisations that I'd already had to put in to placate compiler front ends.
2019-01-03 08:12:19 +00:00
unreachable("Should never see these types on an input file");
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
/*
* Determine the default output file, if none is provided.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
* This will usually be equal to stdout, except that if the
* input and output file formats are the same then the default
* output is to overwrite the input.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
* Also in this code, we bomb out if the input and output file
* formats are the same and no other action is performed.
*/
if ((intype == SSH_KEYTYPE_SSH1 && outtype == PRIVATE) ||
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(intype == SSH_KEYTYPE_SSH2 && outtype == PRIVATE) ||
(intype == SSH_KEYTYPE_OPENSSH_PEM && outtype == OPENSSH_AUTO) ||
(intype == SSH_KEYTYPE_OPENSSH_NEW && outtype == OPENSSH_NEW) ||
(intype == SSH_KEYTYPE_SSHCOM && outtype == SSHCOM)) {
if (!outfile) {
outfile = infile;
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
outfiletmp = dupcat(outfile, ".tmp");
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
cmdgen: add a --reencrypt option. This allows you to load and save the same key without making any semantic changes to it. Currently, you can only do that by pretending to make a change, like changing the passphrase or the comment to the same thing it was before. With two key file formats now supported, and a bunch of reconfigurable parameters in the v3 key derivation, it's now more likely that you'd want to re-encrypt the same key in a different way, to upgrade or downgrade or tinker with it. (Or perhaps even just re-randomise the salt, so that someone reading the key file doesn't know _whether_ you've changed the passphrase!)
2021-02-22 17:56:02 +00:00
if (!change_passphrase && !comment && !reencrypt) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fprintf(stderr, "puttygen: this command would perform no useful"
" action\n");
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!outfile) {
/*
* Bomb out rather than automatically choosing to write
* a private key file to stdout.
*/
if (outtype == PRIVATE || outtype == 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 18:46:58 +00:00
outtype == OPENSSH_NEW || outtype == SSHCOM) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
fprintf(stderr, "puttygen: need to specify an output file\n");
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
/*
* Figure out whether we need to load the encrypted part of the
cmdgen: have --dump output private parts of PPKs. This seems more useful than the previous behaviour of not prompting for a passphrase and only emitting the public part; if we want that back I suppose we could invent a "-O text-public". Also, document the text dump format a bit in the man page.
2021-04-07 21:57:51 +00:00
* key. This will be the case if (a) we need to write out
* a private key format, (b) the entire input key file is
* encrypted, or (c) we're outputting TEXT, in which case we
* want all of the input file including private material if it
* exists.
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
*/
cmdgen: have --dump output private parts of PPKs. This seems more useful than the previous behaviour of not prompting for a passphrase and only emitting the public part; if we want that back I suppose we could invent a "-O text-public". Also, document the text dump format a bit in the man page.
2021-04-07 21:57:51 +00:00
bool intype_entirely_encrypted =
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
intype == SSH_KEYTYPE_OPENSSH_PEM ||
intype == SSH_KEYTYPE_OPENSSH_NEW ||
cmdgen: have --dump output private parts of PPKs. This seems more useful than the previous behaviour of not prompting for a passphrase and only emitting the public part; if we want that back I suppose we could invent a "-O text-public". Also, document the text dump format a bit in the man page.
2021-04-07 21:57:51 +00:00
intype == SSH_KEYTYPE_SSHCOM;
bool intype_has_private =
!(intype == SSH_KEYTYPE_SSH1_PUBLIC ||
intype == SSH_KEYTYPE_SSH2_PUBLIC_RFC4716 ||
intype == SSH_KEYTYPE_SSH2_PUBLIC_OPENSSH);
bool outtype_has_private =
outtype == PRIVATE || outtype == OPENSSH_AUTO ||
outtype == OPENSSH_NEW || outtype == SSHCOM;
if (outtype_has_private || intype_entirely_encrypted ||
(outtype == TEXT && intype_has_private))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
load_encrypted = true;
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
load_encrypted = false;
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
cmdgen: have --dump output private parts of PPKs. This seems more useful than the previous behaviour of not prompting for a passphrase and only emitting the public part; if we want that back I suppose we could invent a "-O text-public". Also, document the text dump format a bit in the man page.
2021-04-07 21:57:51 +00:00
if (load_encrypted && !intype_has_private) {
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 11:19:57 +00:00
fprintf(stderr, "puttygen: cannot perform this action on a "
"public-key-only input file\n");
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
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 11:19:57 +00:00
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
/* ------------------------------------------------------------------
* Now we're ready to actually do some stuff.
*/
/*
* Either load or generate a key.
*/
if (keytype != NOKEYGEN) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *entropy;
char default_comment[80];
struct tm tm;
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
tm = ltime();
if (keytype == DSA)
strftime(default_comment, 30, "dsa-key-%Y%m%d", &tm);
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 09:45:20 +00:00
else if (keytype == ECDSA)
strftime(default_comment, 30, "ecdsa-key-%Y%m%d", &tm);
PuTTYgen: prepare for more general EdDSA. In the Windows GUI, all the controls that were previously named or labelled Ed25519 are now labelled EdDSA, and when you select that top-level key type, there's a dropdown for the specific curve (just like for ECDSA), whose only current value is Ed25519. In command-line PuTTYgen, you can say '-t eddsa' and give a number of bits, just like '-t ecdsa'. You can also still say '-t ed25519', for backwards compatibility. Also in command-line PuTTYgen, I've reworked the error messages if you give a number of bits that doesn't correspond to a known elliptic curve. Now the messages are generated by consulting the list of curves, so that that list has to be updated by hand in one fewer place.
2020-03-02 07:05:19 +00:00
else if (keytype == EDDSA && bits == 255)
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 14:02:54 +00:00
strftime(default_comment, 30, "ed25519-key-%Y%m%d", &tm);
PuTTYgen: prepare for more general EdDSA. In the Windows GUI, all the controls that were previously named or labelled Ed25519 are now labelled EdDSA, and when you select that top-level key type, there's a dropdown for the specific curve (just like for ECDSA), whose only current value is Ed25519. In command-line PuTTYgen, you can say '-t eddsa' and give a number of bits, just like '-t ecdsa'. You can also still say '-t ed25519', for backwards compatibility. Also in command-line PuTTYgen, I've reworked the error messages if you give a number of bits that doesn't correspond to a known elliptic curve. Now the messages are generated by consulting the list of curves, so that that list has to be updated by hand in one fewer place.
2020-03-02 07:05:19 +00:00
else if (keytype == EDDSA)
strftime(default_comment, 30, "eddsa-key-%Y%m%d", &tm);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
else
strftime(default_comment, 30, "rsa-key-%Y%m%d", &tm);
entropy = get_random_data(bits / 8, random_device);
if (!entropy) {
fprintf(stderr, "puttygen: failed to collect entropy, "
"could not generate key\n");
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
random_setup_special();
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-22 22:42:41 +00:00
random_reseed(make_ptrlen(entropy, bits / 8));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
smemclr(entropy, bits/8);
sfree(entropy);
Allow asking for provable primes in PuTTYgen. In Windows PuTTYgen, this is selected by an extra set of radio-button style menu options in the Key menu. In the command-line version, there's a new --primes=provable option. This whole system is new, so I'm not enabling it by default just yet. I may in future, though: it's running faster than I expected (in particular, a lot faster than any previous prototype of the same algorithm I attempted in standalone Python).
2020-02-29 06:43:28 +00:00
PrimeGenerationContext *pgc = primegen_new_context(primegen);
Introduce a vtable system for prime generation. The functions primegen() and primegen_add_progress_phase() are gone. In their place is a small vtable system with two methods corresponding to them, plus the usual admin of allocating and freeing contexts. This API change is the starting point for being able to drop in different prime generation algorithms at run time in response to user configuration.
2020-02-29 09:10:47 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (keytype == DSA) {
struct dss_key *dsskey = snew(struct dss_key);
Introduce a vtable system for prime generation. The functions primegen() and primegen_add_progress_phase() are gone. In their place is a small vtable system with two methods corresponding to them, plus the usual admin of allocating and freeing contexts. This API change is the starting point for being able to drop in different prime generation algorithms at run time in response to user configuration.
2020-02-29 09:10:47 +00:00
dsa_generate(dsskey, bits, pgc, &cmdgen_progress);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ssh2key = snew(ssh2_userkey);
ssh2key->key = &dsskey->sshk;
ssh1key = NULL;
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 09:45:20 +00:00
} else if (keytype == 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 13:53:41 +00:00
struct ecdsa_key *ek = snew(struct ecdsa_key);
New vtable API for keygen progress reporting. The old API was one of those horrible things I used to do when I was young and foolish, in which you have just one function, and indicate which of lots of things it's doing by passing in flags. It was crying out to be replaced with a vtable. While I'm at it, I've reworked the code on the Windows side that decides what to do with the progress bar, so that it's based on actually justifiable estimates of probability rather than magic integer constants. Since computers are generally faster now than they were at the start of this project, I've also decided there's no longer any point in making the fixed final part of RSA key generation bother to report progress at all. So the progress bars are now only for the variable part, i.e. the actual prime generations. (This is a reapplication of commit a7bdefb39, without the Miller-Rabin refactoring accidentally folded into it. Also this time I've added -lm to the link options, which for some reason _didn't_ cause me a link failure last time round. No idea why not.)
2020-02-23 15:29:40 +00:00
ecdsa_generate(ek, bits);
Remove a lot of pointless 'struct' keywords. This is the commit that f3295e0fb _should_ have been. Yesterday I just added some typedefs so that I didn't have to wear out my fingers typing 'struct' in new code, but what I ought to have done is to move all the typedefs into defs.h with the rest, and then go through cleaning up the legacy 'struct's all through the existing code. But I was mostly trying to concentrate on getting the test suite finished, so I just did the minimum. Now it's time to come back and do it better.
2019-01-04 06:51:44 +00:00
ssh2key = snew(ssh2_userkey);
Complete rewrite of PuTTY's bignum library. The old 'Bignum' data type is gone completely, and so is sshbn.c. In its place is a new thing called 'mp_int', handled by an entirely new library module mpint.c, with API differences both large and small. The main aim of this change is that the new library should be free of timing- and cache-related side channels. I've written the code so that it _should_ - assuming I haven't made any mistakes - do all of its work without either control flow or memory addressing depending on the data words of the input numbers. (Though, being an _arbitrary_ precision library, it does have to at least depend on the sizes of the numbers - but there's a 'formal' size that can vary separately from the actual magnitude of the represented integer, so if you want to keep it secret that your number is actually small, it should work fine to have a very long mp_int and just happen to store 23 in it.) So I've done all my conditionalisation by means of computing both answers and doing bit-masking to swap the right one into place, and all loops over the words of an mp_int go up to the formal size rather than the actual size. I haven't actually tested the constant-time property in any rigorous way yet (I'm still considering the best way to do it). But this code is surely at the very least a big improvement on the old version, even if I later find a few more things to fix. I've also completely rewritten the low-level elliptic curve arithmetic from sshecc.c; the new ecc.c is closer to being an adjunct of mpint.c than it is to the SSH end of the code. The new elliptic curve code keeps all coordinates in Montgomery-multiplication transformed form to speed up all the multiplications mod the same prime, and only converts them back when you ask for the affine coordinates. Also, I adopted extended coordinates for the Edwards curve implementation. sshecc.c has also had a near-total rewrite in the course of switching it over to the new system. While I was there, I've separated ECDSA and EdDSA more completely - they now have separate vtables, instead of a single vtable in which nearly every function had a big if statement in it - and also made the externally exposed types for an ECDSA key and an ECDH context different. A minor new feature: since the new arithmetic code includes a modular square root function, we can now support the compressed point representation for the NIST curves. We seem to have been getting along fine without that so far, but it seemed a shame not to put it in, since it was suddenly easy. In sshrsa.c, one major change is that I've removed the RSA blinding step in rsa_privkey_op, in which we randomise the ciphertext before doing the decryption. The purpose of that was to avoid timing leaks giving away the plaintext - but the new arithmetic code should take that in its stride in the course of also being careful enough to avoid leaking the _private key_, which RSA blinding had no way to do anything about in any case. Apart from those specific points, most of the rest of the changes are more or less mechanical, just changing type names and translating code into the new API.
2018-12-31 13:53:41 +00:00
ssh2key->key = &ek->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 09:45:20 +00:00
ssh1key = NULL;
PuTTYgen: prepare for more general EdDSA. In the Windows GUI, all the controls that were previously named or labelled Ed25519 are now labelled EdDSA, and when you select that top-level key type, there's a dropdown for the specific curve (just like for ECDSA), whose only current value is Ed25519. In command-line PuTTYgen, you can say '-t eddsa' and give a number of bits, just like '-t ecdsa'. You can also still say '-t ed25519', for backwards compatibility. Also in command-line PuTTYgen, I've reworked the error messages if you give a number of bits that doesn't correspond to a known elliptic curve. Now the messages are generated by consulting the list of curves, so that that list has to be updated by hand in one fewer place.
2020-03-02 07:05:19 +00:00
} else if (keytype == EDDSA) {
Complete rewrite of PuTTY's bignum library. The old 'Bignum' data type is gone completely, and so is sshbn.c. In its place is a new thing called 'mp_int', handled by an entirely new library module mpint.c, with API differences both large and small. The main aim of this change is that the new library should be free of timing- and cache-related side channels. I've written the code so that it _should_ - assuming I haven't made any mistakes - do all of its work without either control flow or memory addressing depending on the data words of the input numbers. (Though, being an _arbitrary_ precision library, it does have to at least depend on the sizes of the numbers - but there's a 'formal' size that can vary separately from the actual magnitude of the represented integer, so if you want to keep it secret that your number is actually small, it should work fine to have a very long mp_int and just happen to store 23 in it.) So I've done all my conditionalisation by means of computing both answers and doing bit-masking to swap the right one into place, and all loops over the words of an mp_int go up to the formal size rather than the actual size. I haven't actually tested the constant-time property in any rigorous way yet (I'm still considering the best way to do it). But this code is surely at the very least a big improvement on the old version, even if I later find a few more things to fix. I've also completely rewritten the low-level elliptic curve arithmetic from sshecc.c; the new ecc.c is closer to being an adjunct of mpint.c than it is to the SSH end of the code. The new elliptic curve code keeps all coordinates in Montgomery-multiplication transformed form to speed up all the multiplications mod the same prime, and only converts them back when you ask for the affine coordinates. Also, I adopted extended coordinates for the Edwards curve implementation. sshecc.c has also had a near-total rewrite in the course of switching it over to the new system. While I was there, I've separated ECDSA and EdDSA more completely - they now have separate vtables, instead of a single vtable in which nearly every function had a big if statement in it - and also made the externally exposed types for an ECDSA key and an ECDH context different. A minor new feature: since the new arithmetic code includes a modular square root function, we can now support the compressed point representation for the NIST curves. We seem to have been getting along fine without that so far, but it seemed a shame not to put it in, since it was suddenly easy. In sshrsa.c, one major change is that I've removed the RSA blinding step in rsa_privkey_op, in which we randomise the ciphertext before doing the decryption. The purpose of that was to avoid timing leaks giving away the plaintext - but the new arithmetic code should take that in its stride in the course of also being careful enough to avoid leaking the _private key_, which RSA blinding had no way to do anything about in any case. Apart from those specific points, most of the rest of the changes are more or less mechanical, just changing type names and translating code into the new API.
2018-12-31 13:53:41 +00:00
struct eddsa_key *ek = snew(struct eddsa_key);
New vtable API for keygen progress reporting. The old API was one of those horrible things I used to do when I was young and foolish, in which you have just one function, and indicate which of lots of things it's doing by passing in flags. It was crying out to be replaced with a vtable. While I'm at it, I've reworked the code on the Windows side that decides what to do with the progress bar, so that it's based on actually justifiable estimates of probability rather than magic integer constants. Since computers are generally faster now than they were at the start of this project, I've also decided there's no longer any point in making the fixed final part of RSA key generation bother to report progress at all. So the progress bars are now only for the variable part, i.e. the actual prime generations. (This is a reapplication of commit a7bdefb39, without the Miller-Rabin refactoring accidentally folded into it. Also this time I've added -lm to the link options, which for some reason _didn't_ cause me a link failure last time round. No idea why not.)
2020-02-23 15:29:40 +00:00
eddsa_generate(ek, bits);
Remove a lot of pointless 'struct' keywords. This is the commit that f3295e0fb _should_ have been. Yesterday I just added some typedefs so that I didn't have to wear out my fingers typing 'struct' in new code, but what I ought to have done is to move all the typedefs into defs.h with the rest, and then go through cleaning up the legacy 'struct's all through the existing code. But I was mostly trying to concentrate on getting the test suite finished, so I just did the minimum. Now it's time to come back and do it better.
2019-01-04 06:51:44 +00:00
ssh2key = snew(ssh2_userkey);
Complete rewrite of PuTTY's bignum library. The old 'Bignum' data type is gone completely, and so is sshbn.c. In its place is a new thing called 'mp_int', handled by an entirely new library module mpint.c, with API differences both large and small. The main aim of this change is that the new library should be free of timing- and cache-related side channels. I've written the code so that it _should_ - assuming I haven't made any mistakes - do all of its work without either control flow or memory addressing depending on the data words of the input numbers. (Though, being an _arbitrary_ precision library, it does have to at least depend on the sizes of the numbers - but there's a 'formal' size that can vary separately from the actual magnitude of the represented integer, so if you want to keep it secret that your number is actually small, it should work fine to have a very long mp_int and just happen to store 23 in it.) So I've done all my conditionalisation by means of computing both answers and doing bit-masking to swap the right one into place, and all loops over the words of an mp_int go up to the formal size rather than the actual size. I haven't actually tested the constant-time property in any rigorous way yet (I'm still considering the best way to do it). But this code is surely at the very least a big improvement on the old version, even if I later find a few more things to fix. I've also completely rewritten the low-level elliptic curve arithmetic from sshecc.c; the new ecc.c is closer to being an adjunct of mpint.c than it is to the SSH end of the code. The new elliptic curve code keeps all coordinates in Montgomery-multiplication transformed form to speed up all the multiplications mod the same prime, and only converts them back when you ask for the affine coordinates. Also, I adopted extended coordinates for the Edwards curve implementation. sshecc.c has also had a near-total rewrite in the course of switching it over to the new system. While I was there, I've separated ECDSA and EdDSA more completely - they now have separate vtables, instead of a single vtable in which nearly every function had a big if statement in it - and also made the externally exposed types for an ECDSA key and an ECDH context different. A minor new feature: since the new arithmetic code includes a modular square root function, we can now support the compressed point representation for the NIST curves. We seem to have been getting along fine without that so far, but it seemed a shame not to put it in, since it was suddenly easy. In sshrsa.c, one major change is that I've removed the RSA blinding step in rsa_privkey_op, in which we randomise the ciphertext before doing the decryption. The purpose of that was to avoid timing leaks giving away the plaintext - but the new arithmetic code should take that in its stride in the course of also being careful enough to avoid leaking the _private key_, which RSA blinding had no way to do anything about in any case. Apart from those specific points, most of the rest of the changes are more or less mechanical, just changing type names and translating code into the new API.
2018-12-31 13:53:41 +00:00
ssh2key->key = &ek->sshk;
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 14:02:54 +00:00
ssh1key = NULL;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else {
RSAKey *rsakey = snew(RSAKey);
RSA generation: option to generate strong primes. A 'strong' prime, as defined by the Handbook of Applied Cryptography, is a prime p such that each of p-1 and p+1 has a large prime factor, and that the large factor q of p-1 is such that q-1 in turn _also_ has a large prime factor. HoAC says that making your RSA key using primes of this form defeats some factoring algorithms - but there are other faster algorithms to which it makes no difference. So this is probably not a useful precaution in practice. However, it has been recommended in the past by some official standards, and it's easy to implement given the new general facility in PrimeCandidateSource that lets you ask for your prime to satisfy an arbitrary modular congruence. (And HoAC also says there's no particular reason _not_ to use strong primes.) So I provide it as an option, just in case anyone wants to select it. The change to the key generation algorithm is entirely in sshrsag.c, and is neatly independent of the prime-generation system in use. If you're using Maurer provable prime generation, then the known factor q of p-1 can be used to help certify p, and the one for q-1 to help with q in turn; if you switch to probabilistic prime generation then you still get an RSA key with the right structure, except that every time the definition says 'prime factor' you just append '(probably)'. (The probabilistic version of this procedure is described as 'Gordon's algorithm' in HoAC section 4.4.2.)
2020-03-02 06:52:09 +00:00
rsa_generate(rsakey, bits, strong_rsa, pgc, &cmdgen_progress);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
rsakey->comment = NULL;
if (keytype == RSA1) {
ssh1key = rsakey;
} else {
ssh2key = snew(ssh2_userkey);
ssh2key->key = &rsakey->sshk;
}
}
Introduce a vtable system for prime generation. The functions primegen() and primegen_add_progress_phase() are gone. In their place is a small vtable system with two methods corresponding to them, plus the usual admin of allocating and freeing contexts. This API change is the starting point for being able to drop in different prime generation algorithms at run time in response to user configuration.
2020-02-29 09:10:47 +00:00
primegen_free_context(pgc);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (ssh2key)
ssh2key->comment = dupstr(default_comment);
if (ssh1key)
ssh1key->comment = dupstr(default_comment);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
const char *error = NULL;
bool encrypted;
assert(infile != NULL);
sfree(origcomment);
origcomment = NULL;
/*
* Find out whether the input key is encrypted.
*/
if (intype == SSH_KEYTYPE_SSH1)
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
encrypted = rsa1_encrypted_s(infile_bs, &origcomment);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
else if (intype == SSH_KEYTYPE_SSH2)
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
encrypted = ppk_encrypted_s(infile_bs, &origcomment);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
else
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
encrypted = import_encrypted_s(infilename, infile_bs,
intype, &origcomment);
BinarySource_REWIND(infile_bs);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* If so, ask for a passphrase.
*/
if (encrypted && load_encrypted) {
if (!old_passphrase) {
prompts_t *p = new_prompts();
int ret;
p->to_server = false;
p->from_server = false;
p->name = dupstr("SSH key passphrase");
add_prompt(p, dupstr("Enter passphrase to load key: "), false);
ret = console_get_userpass_input(p);
assert(ret >= 0);
if (!ret) {
free_prompts(p);
perror("puttygen: unable to read passphrase");
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else {
Use strbuf to store results in prompts_t. UBsan pointed out another memcpy from NULL (again with length 0) in the prompts_t system. When I looked at it, I realised that firstly prompt_ensure_result_size was an early not-so-good implementation of sgrowarray_nm that would benefit from being replaced with a call to the real one, and secondly, the whole system for storing prompt results should really have been replaced with strbufs with the no-move option, because that's doing all the same jobs better. So, now each prompt_t holds a strbuf in place of its previous manually managed string. prompt_ensure_result_size is gone (the console prompt-reading functions use strbuf_append, and everything else just adds to the strbuf in the usual marshal.c way). New functions exist to retrieve a prompt_t's result, either by reference or copied.
2020-01-21 20:19:47 +00:00
old_passphrase = prompt_get_result(p->prompts[0]);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
free_prompts(p);
}
}
} else {
old_passphrase = NULL;
}
switch (intype) {
int ret;
case SSH_KEYTYPE_SSH1:
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 11:19:57 +00:00
case SSH_KEYTYPE_SSH1_PUBLIC:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ssh1key = snew(RSAKey);
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
memset(ssh1key, 0, sizeof(RSAKey));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!load_encrypted) {
strbuf *blob;
Remove obsolete functions. There are several old functions that the previous commits have removed all, or nearly all, of the references to. match_ssh_id is superseded by ptrlen_eq_string; get_ssh_{string,uint32} is yet another replicated set of decode functions (this time _partly_ centralised into misc.c); the old APIs for the SSH-1 RSA decode functions are gone (together with their last couple of holdout clients), as are ssh{1,2}_{read,write}_bignum and ssh{1,2}_bignum_length. Particularly odd was the use of ssh1_{read,write}_bignum in the SSH-2 Diffie-Hellman implementation. I'd completely forgotten I did that! Now replaced with a raw bignum_from_bytes, which is simpler anyway.
2018-05-29 19:36:21 +00:00
BinarySource src[1];
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
Fix assorted memory leaks. Affects command-line PuTTYgen, PSFTP, and anything running the SSH-2 userauth client layer. Tweaked version of a patch due to Tim Kosse.
2019-07-06 16:44:15 +00:00
sfree(origcomment);
origcomment = NULL;
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 09:59:39 +00:00
blob = strbuf_new();
Fix assorted memory leaks. Affects command-line PuTTYgen, PSFTP, and anything running the SSH-2 userauth client layer. Tweaked version of a patch due to Tim Kosse.
2019-07-06 16:44:15 +00:00
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
ret = rsa1_loadpub_s(infile_bs, BinarySink_UPCAST(blob),
Rename all public/private key load/save functions. Now they have names that are more consistent (no more userkey_this but that_userkey); a bit shorter; and, most importantly, all the current functions end in _f to indicate that they deal with keys stored in disk files. I'm about to add a second set of entry points that deal with keys via the more general BinarySource / BinarySink interface, which will sit alongside these with a different suffix.
2020-01-05 10:28:45 +00:00
&origcomment, &error);
Remove obsolete functions. There are several old functions that the previous commits have removed all, or nearly all, of the references to. match_ssh_id is superseded by ptrlen_eq_string; get_ssh_{string,uint32} is yet another replicated set of decode functions (this time _partly_ centralised into misc.c); the old APIs for the SSH-1 RSA decode functions are gone (together with their last couple of holdout clients), as are ssh{1,2}_{read,write}_bignum and ssh{1,2}_bignum_length. Particularly odd was the use of ssh1_{read,write}_bignum in the SSH-2 Diffie-Hellman implementation. I'd completely forgotten I did that! Now replaced with a raw bignum_from_bytes, which is simpler anyway.
2018-05-29 19:36:21 +00:00
BinarySource_BARE_INIT(src, blob->u, blob->len);
Remove 'keystr' parameter in get_rsa_ssh1_pub. This parameter returned a substring of the input, which was used for two purposes. Firstly, it was used to hash the host and server keys during the initial SSH-1 key setup phase; secondly, it was used to check the keys in Pageant against the public key blob of a key specified on the command line. Unfortunately, those two purposes didn't agree! The first one needs just the bare key modulus bytes (without even the SSH-1 mpint length header); the second needs the entire key blob. So, actually, it seems to have never worked in SSH-1 to say 'putty -i keyfile' and have PuTTY find that key in Pageant and not have to ask for the passphrase to decrypt the version on disk. Fixed by removing that parameter completely, which simplifies all the _other_ call sites, and replacing it by custom code in those two places that each does the actually right thing.
2018-06-03 07:23:07 +00:00
get_rsa_ssh1_pub(src, ssh1key, RSA_SSH1_EXPONENT_FIRST);
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 09:59:39 +00:00
strbuf_free(blob);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ssh1key->comment = dupstr(origcomment);
ssh1key->private_exponent = NULL;
ssh1key->p = NULL;
ssh1key->q = NULL;
ssh1key->iqmp = NULL;
} else {
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
ret = rsa1_load_s(infile_bs, ssh1key, old_passphrase, &error);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
BinarySource_REWIND(infile_bs);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (ret > 0)
error = NULL;
else if (!error)
error = "unknown error";
break;
case SSH_KEYTYPE_SSH2:
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 11:19:57 +00:00
case SSH_KEYTYPE_SSH2_PUBLIC_RFC4716:
case SSH_KEYTYPE_SSH2_PUBLIC_OPENSSH:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!load_encrypted) {
Fix assorted memory leaks. Affects command-line PuTTYgen, PSFTP, and anything running the SSH-2 userauth client layer. Tweaked version of a patch due to Tim Kosse.
2019-07-06 16:44:15 +00:00
sfree(origcomment);
origcomment = NULL;
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 09:59:39 +00:00
ssh2blob = strbuf_new();
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
if (ppk_loadpub_s(infile_bs, &ssh2alg,
Rename all public/private key load/save functions. Now they have names that are more consistent (no more userkey_this but that_userkey); a bit shorter; and, most importantly, all the current functions end in _f to indicate that they deal with keys stored in disk files. I'm about to add a second set of entry points that deal with keys via the more general BinarySource / BinarySink interface, which will sit alongside these with a different suffix.
2020-01-05 10:28:45 +00:00
BinarySink_UPCAST(ssh2blob),
&origcomment, &error)) {
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 11:58:05 +00:00
const ssh_keyalg *alg = find_pubkey_alg(ssh2alg);
if (alg)
bits = ssh_key_public_bits(
New utility functions to make ptrlens. One to make one from a NUL-terminated string, and another to make one from a strbuf. I've switched over all the obvious cases where I should have been using these functions.
2018-10-13 15:30:59 +00:00
alg, ptrlen_from_strbuf(ssh2blob));
Give a better error message if a PuTTY private key file has a version number we don't understand. It's nicer to report 'format too new' than 'not a PuTTY key file'. [originally from svn r9763]
2013-02-22 21:39:02 +00:00
else
bits = -1;
Change ssh.h crypto APIs to output to BinarySink. This affects all the functions that generate public and private key and signature blobs of all kinds, plus ssh_ecdhkex_getpublic. Instead of returning a bare block of memory and taking an extra 'int *length' parameter, all these functions now write to a BinarySink, and it's the caller's job to have prepared an appropriate one where they want the output to go (usually a strbuf). The main value of this change is that those blob-generation functions were chock full of ad-hoc length-counting and data marshalling. You have only to look at rsa2_{public,private}_blob, for example, to see the kind of thing I was keen to get rid of!
2018-05-24 09:59:39 +00:00
} else {
strbuf_free(ssh2blob);
cmdgen: fix error report after ssh2_userkey_loadpub fails. We strbuf_free(ssh2blob), but forgot to null the pointer out afterwards, which means a subsequent check for NULL believes there wasn't a problem, and nulls out the error message pointer instead!
2019-01-29 20:12:37 +00:00
ssh2blob = NULL;
Give a better error message if a PuTTY private key file has a version number we don't understand. It's nicer to report 'format too new' than 'not a PuTTY key file'. [originally from svn r9763]
2013-02-22 21:39:02 +00:00
}
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 09:12:06 +00:00
sfree(ssh2alg);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else {
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
ssh2key = ppk_load_s(infile_bs, old_passphrase, &error);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
BinarySource_REWIND(infile_bs);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if ((ssh2key && ssh2key != SSH2_WRONG_PASSPHRASE) || ssh2blob)
error = NULL;
else if (!error) {
if (ssh2key == SSH2_WRONG_PASSPHRASE)
error = "wrong passphrase";
else
error = "unknown error";
}
break;
case SSH_KEYTYPE_OPENSSH_PEM:
case SSH_KEYTYPE_OPENSSH_NEW:
case SSH_KEYTYPE_SSHCOM:
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
ssh2key = import_ssh2_s(infile_bs, intype, old_passphrase, &error);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (ssh2key) {
if (ssh2key != SSH2_WRONG_PASSPHRASE)
error = NULL;
else
error = "wrong passphrase";
} else if (!error)
error = "unknown error";
break;
default:
unreachable("bad input key type");
}
if (error) {
fprintf(stderr, "puttygen: error loading `%s': %s\n",
infile, error);
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
/*
* Change the comment if asked to.
*/
if (comment) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (sshver == 1) {
assert(ssh1key);
sfree(ssh1key->comment);
ssh1key->comment = dupstr(comment);
} else {
assert(ssh2key);
sfree(ssh2key->comment);
ssh2key->comment = dupstr(comment);
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
Add command-line passphrase-file options to command-line PuTTYgen. Patch due to Colin Watson. Putting the passphrase in a file avoids exposing it to 'ps' which can print out every process's command line, while at the same time not being as platform-specific as the approach of providing an fd number (since cmdgen.c is in principle a potential cross-platform PuTTYgen, not just a Unix one, which is why it's not in the 'unix' directory). Of course it introduces its own risks if someone can read the file from your disk after you delete it; probably the best approach to avoiding this, if possible, is to point the option at a file on an in-memory tmpfs type file system. Or better still, use bash-style /dev/fd options such as puttygen --new-passphrase <(echo -n "my passphrase") [options] Failing that, try a secure file-wipe utility, as the man page change mentions. (And a use case not to be overlooked, of course, is the one where you actually want to generate an unprotected key - in which case, just pass /dev/null as the filename.)
2016-03-17 18:42:46 +00:00
/*
* Unless we're changing the passphrase, the old one (if any) is a
* reasonable default.
*/
if (!change_passphrase && old_passphrase && !new_passphrase)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
new_passphrase = dupstr(old_passphrase);
Add command-line passphrase-file options to command-line PuTTYgen. Patch due to Colin Watson. Putting the passphrase in a file avoids exposing it to 'ps' which can print out every process's command line, while at the same time not being as platform-specific as the approach of providing an fd number (since cmdgen.c is in principle a potential cross-platform PuTTYgen, not just a Unix one, which is why it's not in the 'unix' directory). Of course it introduces its own risks if someone can read the file from your disk after you delete it; probably the best approach to avoiding this, if possible, is to point the option at a file on an in-memory tmpfs type file system. Or better still, use bash-style /dev/fd options such as puttygen --new-passphrase <(echo -n "my passphrase") [options] Failing that, try a secure file-wipe utility, as the man page change mentions. (And a use case not to be overlooked, of course, is the one where you actually want to generate an unprotected key - in which case, just pass /dev/null as the filename.)
2016-03-17 18:42:46 +00:00
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
/*
* Prompt for a new passphrase if we have been asked to, or if
* we have just generated a key.
cmdgen: add a --dump option. Also spelled '-O text', this takes a public or private key as input, and produces on standard output a dump of all the actual numbers involved in the key: the exponent and modulus for RSA, the p,q,g,y parameters for DSA, the affine x and y coordinates of the public elliptic curve point for ECC keys, and all the extra bits and pieces in the private keys too. Partly I expect this to be useful to me for debugging: I've had to paste key files a few too many times through base64 decoders and hex dump tools, then manually decode SSH marshalling and paste the result into the Python REPL to get an integer object. Now I should be able to get _straight_ to text I can paste into Python. But also, it's a way that other applications can use the key generator: if you need to generate, say, an RSA key in some format I don't support (I've recently heard of an XML-based one, for example), then you can run 'puttygen -t rsa --dump' and have it print the elements of a freshly generated keypair on standard output, and then all you have to do is understand the output format.
2020-02-17 19:53:19 +00:00
*
* In the latter case, an exception is if we're producing text
* output, because that output format doesn't support encryption
* in any case.
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
*/
cmdgen: add a --dump option. Also spelled '-O text', this takes a public or private key as input, and produces on standard output a dump of all the actual numbers involved in the key: the exponent and modulus for RSA, the p,q,g,y parameters for DSA, the affine x and y coordinates of the public elliptic curve point for ECC keys, and all the extra bits and pieces in the private keys too. Partly I expect this to be useful to me for debugging: I've had to paste key files a few too many times through base64 decoders and hex dump tools, then manually decode SSH marshalling and paste the result into the Python REPL to get an integer object. Now I should be able to get _straight_ to text I can paste into Python. But also, it's a way that other applications can use the key generator: if you need to generate, say, an RSA key in some format I don't support (I've recently heard of an XML-based one, for example), then you can run 'puttygen -t rsa --dump' and have it print the elements of a freshly generated keypair on standard output, and then all you have to do is understand the output format.
2020-02-17 19:53:19 +00:00
if (!new_passphrase && (change_passphrase ||
(keytype != NOKEYGEN && outtype != TEXT))) {
Make prototype for new_prompts() consistent. In commit b4c8fd9d8 which introduced the Seat trait, I got a bit confused about the prototype of new_prompts(). Previously it took a 'Frontend *' parameter; I edited the call sites to pass a 'Seat *' instead, but the actual function definition takes no parameters at all - and rightly so, because the 'Frontend *' inside the prompts_t has been removed and _not_ replaced with a 'Seat *', so the constructor would have nothing to do with such a thing anyway. But I wrote the function declaration in putty.h with '()' rather than '(void)' (too much time spent in C++), and so the compiler never spotted the mismatch. Now new_prompts() is consistently nullary everywhere it appears: the prototype in the header is a proper (void) one, and the call sites have been modified to not pointlessly give it a Seat or null pointer.
2020-01-29 06:13:41 +00:00
prompts_t *p = new_prompts();
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int ret;
p->to_server = false;
p->from_server = false;
p->name = dupstr("New SSH key passphrase");
add_prompt(p, dupstr("Enter passphrase to save key: "), false);
add_prompt(p, dupstr("Re-enter passphrase to verify: "), false);
ret = console_get_userpass_input(p);
assert(ret >= 0);
if (!ret) {
free_prompts(p);
perror("puttygen: unable to read new passphrase");
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
} else {
Use strbuf to store results in prompts_t. UBsan pointed out another memcpy from NULL (again with length 0) in the prompts_t system. When I looked at it, I realised that firstly prompt_ensure_result_size was an early not-so-good implementation of sgrowarray_nm that would benefit from being replaced with a call to the real one, and secondly, the whole system for storing prompt results should really have been replaced with strbufs with the no-move option, because that's doing all the same jobs better. So, now each prompt_t holds a strbuf in place of its previous manually managed string. prompt_ensure_result_size is gone (the console prompt-reading functions use strbuf_append, and everything else just adds to the strbuf in the usual marshal.c way). New functions exist to retrieve a prompt_t's result, either by reference or copied.
2020-01-21 20:19:47 +00:00
if (strcmp(prompt_get_result_ref(p->prompts[0]),
prompt_get_result_ref(p->prompts[1]))) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
free_prompts(p);
fprintf(stderr, "puttygen: passphrases do not match\n");
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Use strbuf to store results in prompts_t. UBsan pointed out another memcpy from NULL (again with length 0) in the prompts_t system. When I looked at it, I realised that firstly prompt_ensure_result_size was an early not-so-good implementation of sgrowarray_nm that would benefit from being replaced with a call to the real one, and secondly, the whole system for storing prompt results should really have been replaced with strbufs with the no-move option, because that's doing all the same jobs better. So, now each prompt_t holds a strbuf in place of its previous manually managed string. prompt_ensure_result_size is gone (the console prompt-reading functions use strbuf_append, and everything else just adds to the strbuf in the usual marshal.c way). New functions exist to retrieve a prompt_t's result, either by reference or copied.
2020-01-21 20:19:47 +00:00
new_passphrase = prompt_get_result(p->prompts[0]);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
free_prompts(p);
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
Add command-line passphrase-file options to command-line PuTTYgen. Patch due to Colin Watson. Putting the passphrase in a file avoids exposing it to 'ps' which can print out every process's command line, while at the same time not being as platform-specific as the approach of providing an fd number (since cmdgen.c is in principle a potential cross-platform PuTTYgen, not just a Unix one, which is why it's not in the 'unix' directory). Of course it introduces its own risks if someone can read the file from your disk after you delete it; probably the best approach to avoiding this, if possible, is to point the option at a file on an in-memory tmpfs type file system. Or better still, use bash-style /dev/fd options such as puttygen --new-passphrase <(echo -n "my passphrase") [options] Failing that, try a secure file-wipe utility, as the man page change mentions. (And a use case not to be overlooked, of course, is the one where you actually want to generate an unprotected key - in which case, just pass /dev/null as the filename.)
2016-03-17 18:42:46 +00:00
if (new_passphrase && !*new_passphrase) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(new_passphrase);
new_passphrase = NULL;
Add command-line passphrase-file options to command-line PuTTYgen. Patch due to Colin Watson. Putting the passphrase in a file avoids exposing it to 'ps' which can print out every process's command line, while at the same time not being as platform-specific as the approach of providing an fd number (since cmdgen.c is in principle a potential cross-platform PuTTYgen, not just a Unix one, which is why it's not in the 'unix' directory). Of course it introduces its own risks if someone can read the file from your disk after you delete it; probably the best approach to avoiding this, if possible, is to point the option at a file on an in-memory tmpfs type file system. Or better still, use bash-style /dev/fd options such as puttygen --new-passphrase <(echo -n "my passphrase") [options] Failing that, try a secure file-wipe utility, as the man page change mentions. (And a use case not to be overlooked, of course, is the one where you actually want to generate an unprotected key - in which case, just pass /dev/null as the filename.)
2016-03-17 18:42:46 +00:00
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
/*
* Write output.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
* (In the case where outfile and outfiletmp are both NULL,
* there is no semantic reason to initialise outfilename at
* all; but we have to write _something_ to it or some compiler
* will probably complain that it might be used uninitialised.)
*/
if (outfiletmp)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
outfilename = filename_from_str(outfiletmp);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
outfilename = filename_from_str(outfile ? outfile : "");
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
switch (outtype) {
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool ret;
int real_outtype;
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
case PRIVATE:
cgtest: call random_ref() before saving private keys. The save functions do need some random data (for padding encrypted blocks), so we must ensure a PRNG is available to generate that data.
2019-03-24 14:05:35 +00:00
random_ref(); /* we'll need a few random bytes in the save file */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (sshver == 1) {
assert(ssh1key);
Rename all public/private key load/save functions. Now they have names that are more consistent (no more userkey_this but that_userkey); a bit shorter; and, most importantly, all the current functions end in _f to indicate that they deal with keys stored in disk files. I'm about to add a second set of entry points that deal with keys via the more general BinarySource / BinarySink interface, which will sit alongside these with a different suffix.
2020-01-05 10:28:45 +00:00
ret = rsa1_save_f(outfilename, ssh1key, new_passphrase);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!ret) {
fprintf(stderr, "puttygen: unable to save SSH-1 private key\n");
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
} else {
assert(ssh2key);
cmdgen: command-line control of PPK save parameters. This allows you to manually adjust the Argon2 parameters so that you can trade off CPU requirements in legitimate use against difficulty of brute-force attack. It also allows downgrading the key file version back to the widespread PPK v2, so you can manually back-port a key that you accidentally generated too new.
2021-02-22 18:13:12 +00:00
ret = ppk_save_f(outfilename, ssh2key, new_passphrase, &params);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!ret) {
fprintf(stderr, "puttygen: unable to save SSH-2 private key\n");
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
}
if (outfiletmp) {
if (!move(outfiletmp, outfile))
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1); /* rename failed */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
break;
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
case PUBLIC:
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
case PUBLICO: {
FILE *fp;
if (outfile) {
fp = f_open(outfilename, "w", false);
if (!fp) {
fprintf(stderr, "unable to open output file\n");
exit(1);
}
} else {
fp = stdout;
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (sshver == 1) {
ssh1_write_pubkey(fp, ssh1key);
} else {
if (!ssh2blob) {
assert(ssh2key);
ssh2blob = strbuf_new();
ssh_key_public_blob(ssh2key->key, BinarySink_UPCAST(ssh2blob));
}
ssh2_write_pubkey(fp, ssh2key ? ssh2key->comment : origcomment,
ssh2blob->s, ssh2blob->len,
(outtype == PUBLIC ?
SSH_KEYTYPE_SSH2_PUBLIC_RFC4716 :
SSH_KEYTYPE_SSH2_PUBLIC_OPENSSH));
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (outfile)
fclose(fp);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
case FP: {
FILE *fp;
char *fingerprint;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (sshver == 1) {
assert(ssh1key);
fingerprint = rsa_ssh1_fingerprint(ssh1key);
} else {
if (ssh2key) {
cmdgen: support configurable key fingerprint type. I've added the -E option, similar to ssh-keygen's, and cgtest checks it against the OpenSSH version to ensure they match.
2021-03-13 09:57:02 +00:00
fingerprint = ssh2_fingerprint(ssh2key->key, fptype);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
} else {
assert(ssh2blob);
fingerprint = ssh2_fingerprint_blob(
cmdgen: support configurable key fingerprint type. I've added the -E option, similar to ssh-keygen's, and cgtest checks it against the OpenSSH version to ensure they match.
2021-03-13 09:57:02 +00:00
ptrlen_from_strbuf(ssh2blob), fptype);
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
if (outfile) {
fp = f_open(outfilename, "w", false);
if (!fp) {
fprintf(stderr, "unable to open output file\n");
exit(1);
}
} else {
fp = stdout;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
fprintf(fp, "%s\n", fingerprint);
if (outfile)
fclose(fp);
sfree(fingerprint);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
break;
Formatting change to braces around one case of a switch. Sometimes, within a switch statement, you want to declare local variables specific to the handler for one particular case. Until now I've mostly been writing this in the form switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; } break; } which is ugly because the two pieces of essentially similar code appear at different indent levels, and also inconvenient because you have less horizontal space available to write the complicated case handler in - particuarly undesirable because _complicated_ case handlers are the ones most likely to need all the space they can get! After encountering a rather nicer idiom in the LLVM source code, and after a bit of hackery this morning figuring out how to persuade Emacs's auto-indent to do what I wanted with it, I've decided to move to an idiom in which the open brace comes right after the case statement, and the code within it is indented the same as it would have been without the brace. Then the whole case handler (including the break) lives inside those braces, and you get something that looks more like this: switch (discriminant) { case SIMPLE: do stuff; break; case COMPLICATED: { declare variables; do stuff; break; } } This commit is a big-bang change that reformats all the complicated case handlers I could find into the new layout. This is particularly nice in the Pageant main function, in which almost _every_ case handler had a bundle of variables and was long and complicated. (In fact that's what motivated me to get round to this.) Some of the innermost parts of the terminal escape-sequence handling are also breathing a bit easier now the horizontal pressure on them is relieved. (Also, in a few cases, I was able to remove the extra braces completely, because the only variable local to the case handler was a loop variable which our new C99 policy allows me to move into the initialiser clause of its for statement.) Viewed with whitespace ignored, this is not too disruptive a change. Downstream patches that conflict with it may need to be reapplied using --ignore-whitespace or similar.
2020-02-16 07:49:52 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
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 06:42:48 +00:00
case 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 18:46:58 +00:00
case OPENSSH_NEW:
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
case SSHCOM:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
assert(sshver == 2);
assert(ssh2key);
random_ref(); /* both foreign key types require randomness,
Fix assertion failure in Unix PuTTYgen exports. The assertions I added to sshrand.c in r9930 are now justified, because they were failing when cmdgen was used to convert a key into either foreign private key file format - both the export functions require random_byte() for one reason or another, and random_ref() hadn't been called first. [originally from svn r10117] [r9930 == 33f485c1c3a0942192763f085292aa57d9c3de87]
2014-01-16 19:16:19 +00:00
* for IV or padding */
Fix enum-conflation in cmdgen.c. I'd somehow managed to declare an enum in cmdgen.c with key types OPENSSH and SSHCOM, and use it interchangeably with the one in ssh.h with SSH_KEYTYPE_OPENSSH and SSH_KEYTYPE_SSHCOM. It so happened that the relevant two enum values matched up! So this hasn't caused a bug yet, but it's an accident waiting to happen. Fix it before it does.
2015-04-28 18:46:08 +00:00
switch (outtype) {
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 06:42:48 +00:00
case OPENSSH_AUTO:
real_outtype = 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 18:46:58 +00:00
break;
case OPENSSH_NEW:
real_outtype = SSH_KEYTYPE_OPENSSH_NEW;
Fix enum-conflation in cmdgen.c. I'd somehow managed to declare an enum in cmdgen.c with key types OPENSSH and SSHCOM, and use it interchangeably with the one in ssh.h with SSH_KEYTYPE_OPENSSH and SSH_KEYTYPE_SSHCOM. It so happened that the relevant two enum values matched up! So this hasn't caused a bug yet, but it's an accident waiting to happen. Fix it before it does.
2015-04-28 18:46:08 +00:00
break;
case SSHCOM:
real_outtype = SSH_KEYTYPE_SSHCOM;
break;
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 18:46:58 +00:00
default:
Replace assert(false) with an unreachable() macro. Taking a leaf out of the LLVM code base: this macro still includes an assert(false) so that the message will show up in a typical build, but it follows it up with a call to a function explicitly marked as no- return. So this ought to do a better job of convincing compilers that once a code path hits this function it _really doesn't_ have to still faff about with making up a bogus return value or filling in a variable that 'might be used uninitialised' in the following code that won't be reached anyway. I've gone through the existing code looking for the assert(false) / assert(0) idiom and replaced all the ones I found with the new macro, which also meant I could remove a few pointless return statements and variable initialisations that I'd already had to put in to placate compiler front ends.
2019-01-03 08:12:19 +00:00
unreachable("control flow goof");
Fix enum-conflation in cmdgen.c. I'd somehow managed to declare an enum in cmdgen.c with key types OPENSSH and SSHCOM, and use it interchangeably with the one in ssh.h with SSH_KEYTYPE_OPENSSH and SSH_KEYTYPE_SSHCOM. It so happened that the relevant two enum values matched up! So this hasn't caused a bug yet, but it's an accident waiting to happen. Fix it before it does.
2015-04-28 18:46:08 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ret = export_ssh2(outfilename, real_outtype, ssh2key, new_passphrase);
if (!ret) {
fprintf(stderr, "puttygen: unable to export key\n");
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
if (outfiletmp) {
if (!move(outfiletmp, outfile))
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
RETURN(1); /* rename failed */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
break;
cmdgen: add a --dump option. Also spelled '-O text', this takes a public or private key as input, and produces on standard output a dump of all the actual numbers involved in the key: the exponent and modulus for RSA, the p,q,g,y parameters for DSA, the affine x and y coordinates of the public elliptic curve point for ECC keys, and all the extra bits and pieces in the private keys too. Partly I expect this to be useful to me for debugging: I've had to paste key files a few too many times through base64 decoders and hex dump tools, then manually decode SSH marshalling and paste the result into the Python REPL to get an integer object. Now I should be able to get _straight_ to text I can paste into Python. But also, it's a way that other applications can use the key generator: if you need to generate, say, an RSA key in some format I don't support (I've recently heard of an XML-based one, for example), then you can run 'puttygen -t rsa --dump' and have it print the elements of a freshly generated keypair on standard output, and then all you have to do is understand the output format.
2020-02-17 19:53:19 +00:00
case TEXT: {
key_components *kc;
if (sshver == 1) {
assert(ssh1key);
kc = rsa_components(ssh1key);
} else {
if (ssh2key) {
kc = ssh_key_components(ssh2key->key);
} else {
assert(ssh2blob);
BinarySource src[1];
BinarySource_BARE_INIT_PL(src, ptrlen_from_strbuf(ssh2blob));
ptrlen algname = get_string(src);
const ssh_keyalg *alg = find_pubkey_alg_len(algname);
if (!alg) {
fprintf(stderr, "puttygen: cannot extract key components "
"from public key of unknown type '%.*s'\n",
PTRLEN_PRINTF(algname));
RETURN(1);
}
ssh_key *sk = ssh_key_new_pub(
alg, ptrlen_from_strbuf(ssh2blob));
kc = ssh_key_components(sk);
ssh_key_free(sk);
}
}
FILE *fp;
if (outfile) {
fp = f_open(outfilename, "w", false);
if (!fp) {
fprintf(stderr, "unable to open output file\n");
exit(1);
}
} else {
fp = stdout;
}
for (size_t i = 0; i < kc->ncomponents; i++) {
if (kc->components[i].is_mp_int) {
char *hex = mp_get_hex(kc->components[i].mp);
fprintf(fp, "%s=0x%s\n", kc->components[i].name, hex);
smemclr(hex, strlen(hex));
sfree(hex);
} else {
fprintf(fp, "%s=\"", kc->components[i].name);
write_c_string_literal(fp, ptrlen_from_asciz(
kc->components[i].text));
fputs("\"\n", fp);
}
}
if (outfile)
fclose(fp);
key_components_free(kc);
break;
}
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
out:
#undef RETURN
Add command-line passphrase-file options to command-line PuTTYgen. Patch due to Colin Watson. Putting the passphrase in a file avoids exposing it to 'ps' which can print out every process's command line, while at the same time not being as platform-specific as the approach of providing an fd number (since cmdgen.c is in principle a potential cross-platform PuTTYgen, not just a Unix one, which is why it's not in the 'unix' directory). Of course it introduces its own risks if someone can read the file from your disk after you delete it; probably the best approach to avoiding this, if possible, is to point the option at a file on an in-memory tmpfs type file system. Or better still, use bash-style /dev/fd options such as puttygen --new-passphrase <(echo -n "my passphrase") [options] Failing that, try a secure file-wipe utility, as the man page change mentions. (And a use case not to be overlooked, of course, is the one where you actually want to generate an unprotected key - in which case, just pass /dev/null as the filename.)
2016-03-17 18:42:46 +00:00
if (old_passphrase) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
smemclr(old_passphrase, strlen(old_passphrase));
sfree(old_passphrase);
Add command-line passphrase-file options to command-line PuTTYgen. Patch due to Colin Watson. Putting the passphrase in a file avoids exposing it to 'ps' which can print out every process's command line, while at the same time not being as platform-specific as the approach of providing an fd number (since cmdgen.c is in principle a potential cross-platform PuTTYgen, not just a Unix one, which is why it's not in the 'unix' directory). Of course it introduces its own risks if someone can read the file from your disk after you delete it; probably the best approach to avoiding this, if possible, is to point the option at a file on an in-memory tmpfs type file system. Or better still, use bash-style /dev/fd options such as puttygen --new-passphrase <(echo -n "my passphrase") [options] Failing that, try a secure file-wipe utility, as the man page change mentions. (And a use case not to be overlooked, of course, is the one where you actually want to generate an unprotected key - in which case, just pass /dev/null as the filename.)
2016-03-17 18:42:46 +00:00
}
if (new_passphrase) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
smemclr(new_passphrase, strlen(new_passphrase));
sfree(new_passphrase);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
Fix some minor memory leaks in cmdgen. I happened to run cmdgen under Leak Sanitiser, and found it was _almost_ clean - clean enough that if I fix the last few leaks then it might be worth running it again from time to time.
2018-12-30 14:14:59 +00:00
if (ssh1key) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
freersakey(ssh1key);
cmdgen: fix a tiny memory leak. One of those things you'd never notice if it weren't for Leak Sanitiser happening to be turned on while you were doing something else: freersakey() frees all the things pointed to _from_ an RSAKey structure, but not the structure itself.
2019-06-28 18:22:39 +00:00
sfree(ssh1key);
Fix some minor memory leaks in cmdgen. I happened to run cmdgen under Leak Sanitiser, and found it was _almost_ clean - clean enough that if I fix the last few leaks then it might be worth running it again from time to time.
2018-12-30 14:14:59 +00:00
}
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
if (ssh2key && ssh2key != SSH2_WRONG_PASSPHRASE) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(ssh2key->comment);
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
if (ssh2key->key)
ssh_key_free(ssh2key->key);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
sfree(ssh2key);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
Fix assorted memory leaks. Affects command-line PuTTYgen, PSFTP, and anything running the SSH-2 userauth client layer. Tweaked version of a patch due to Tim Kosse.
2019-07-06 16:44:15 +00:00
if (ssh2blob)
strbuf_free(ssh2blob);
Fix a few memory leaks. Mostly noticed in passing while using Address / Leak Sanitiser to check over the previous commit. One highlight here is freeing of the previous iqmp value in rsa_verify, which was actually a potentially sensitive leak, introduced in the mp_int rewrite (commit 25b034ee3).
2019-02-28 06:19:31 +00:00
sfree(origcomment);
if (infilename)
filename_free(infilename);
Allow cmdgen to read keys from standard input. This reworks the cmdgen main program so that it loads the input file into a LoadedFile right at the start, and then every time it needs to do something with the contents, it calls one of the API functions taking a BinarySource instead of one taking a Filename. The usefulness of this is that now we can read from things that aren't regular files, and can't be rewound or reopened. In particular, the filename "-" is now taken (per the usual convention) to mean standard input. So now you can pipe a public or private key file into cmdgen's standard input and have it do something useful. For example, I was recently experimenting with the SFTP-only SSH server that comes with 'proftpd', which keeps its authorized_keys file in RFC 4716 format instead of the OpenSSH one-liner format, and I found I wanted to do grep 'my-key-comment' ~/.ssh/authorized_keys | puttygen -p - to quickly get hold of my existing public key to put in that file. But I had to go via a temporary file to make that work, because puttygen couldn't read from standard input. Next time, it will be able to!
2020-02-02 11:41:06 +00:00
if (infile_lf)
lf_free(infile_lf);
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
if (outfilename)
filename_free(outfilename);
sfree(outfiletmp);
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
cgtest: fix all memory leaks. I've adjusted the cmdgen main program so that it does all early returns via the 'goto out' idiom, so that they still go through all the last-minute freeing steps. That meant I had to adjust a few of the last-minute freeing steps so they don't try to do impossible things like freeing SSH2_WRONG_PASSPHRASE or calling a vtable method of a null object. Also added a couple of completely missing frees, in cmdgen itself ('outfiletmp') and in the cgtest wrapper main ('fp'). Now cgtest gets a completely clean run through Leak Sanitiser.
2020-01-13 22:14:02 +00:00
return exit_status;
Added a command-line key generation tool. Currently builds and runs on Linux, but the (very few) platform-specific bits are already abstracted out of the main code, so it should port to other platforms with a minimum of fuss. [originally from svn r3762]
2004-01-22 19:15:32 +00:00
}
Reference in New Issue Copy Permalink