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

640 lines
19 KiB
C
Raw Permalink Normal View History

Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
/*
* GTK implementation of a GUI password/passphrase prompt.
*/
#include <assert.h>
#include <time.h>
#include <stdlib.h>
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
#include <unistd.h>
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
#include <gtk/gtk.h>
GTK 3 prep: do not include individual GTK/GDK headers. This is the first of several cleanup steps recommended by the GTK 2->3 migration guide. I intend to begin work towards compatibility with GTK 3, but without breaking GTK 2 and even GTK 1 compatibility in the process; GTK 2 is still useful to _me_ (not least because it permits much easier support of old-style server-side X11 fonts), and I recall hearing a rumour that at least one kind of strange system can only run GTK 1, so for the moment I don't intend to stop supporting either. Including gdkkeysyms.h is not optional in GTK 2, because gdk.h does not include it. In GTK 3 it does, so we don't explicitly reinclude it ourselves. We now build cleanly in GTK2 with -DGTK_DISABLE_SINGLE_INCLUDES. (But that doesn't say much, because we did already! Apparently gdkkeysyms.h was a special case which that #define didn't forbid.)
2015-08-08 14:06:15 +00:00
#include <gdk/gdk.h>
#if !GTK_CHECK_VERSION(3,0,0)
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
#include <gdk/gdkkeysyms.h>
GTK 3 prep: do not include individual GTK/GDK headers. This is the first of several cleanup steps recommended by the GTK 2->3 migration guide. I intend to begin work towards compatibility with GTK 3, but without breaking GTK 2 and even GTK 1 compatibility in the process; GTK 2 is still useful to _me_ (not least because it permits much easier support of old-style server-side X11 fonts), and I recall hearing a rumour that at least one kind of strange system can only run GTK 1, so for the moment I don't intend to stop supporting either. Including gdkkeysyms.h is not optional in GTK 2, because gdk.h does not include it. In GTK 3 it does, so we don't explicitly reinclude it ourselves. We now build cleanly in GTK2 with -DGTK_DISABLE_SINGLE_INCLUDES. (But that doesn't say much, because we did already! Apparently gdkkeysyms.h was a special case which that #define didn't forbid.)
2015-08-08 14:06:15 +00:00
#endif
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
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
#include "defs.h"
Rename most of the platform source files. This gets rid of all those annoying 'win', 'ux' and 'gtk' prefixes which made filenames annoying to type and to tab-complete. Also, as with my other recent renaming sprees, I've taken the opportunity to expand and clarify some of the names so that they're not such cryptic abbreviations.
2021-04-23 05:19:05 +00:00
#include "unifont.h"
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
#include "gtkcompat.h"
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
#include "gtkmisc.h"
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
Use a proper PRNG for GTK askpass. Coverity complained that it was wrong to use rand() in a security context, and although in this case it's _very_ marginal, I can't actually disagree that the choice of which light to light up to avoid giving information about passphrase length is a security context. So, no more rand(); instead we instantiate a shiny Fortuna PRNG instance, seed it in more or less the usual way, and use that as an overkill-level method of choosing which light to light up next. (Acknowledging that this is a slightly unusual application and less critical than most, I don't actually put the passphrase characters themselves into the PRNG, and I don't use a random-seed file.)
2019-05-05 19:22:36 +00:00
#include "putty.h"
#include "ssh.h"
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
#include "misc.h"
#define N_DRAWING_AREAS 3
struct drawing_area_ctx {
GtkWidget *area;
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
#ifndef DRAW_DEFAULT_CAIRO
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
GdkColor *cols;
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
#endif
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
int width, height;
enum { NOT_CURRENT, CURRENT, GREYED_OUT } state;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
};
struct askpass_ctx {
GtkWidget *dialog, *promptlabel;
struct drawing_area_ctx drawingareas[N_DRAWING_AREAS];
int active_area;
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
GtkIMContext *imc;
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
#endif
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
#ifndef DRAW_DEFAULT_CAIRO
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
GdkColormap *colmap;
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
GdkColor cols[3];
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
#endif
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
char *error_message; /* if we finish without a passphrase */
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
strbuf *passphrase; /* if we finish with one */
GTK 3.20 compatibility: switch to gdk_seat_grab. gdk_device_grab and all its preparatory faff are now deprecated, and gdk_seat_grab is the new thing. Introduce yet another branch to all the ifdefs for keyboard-grabbing. On the plus side, at least it's slightly simpler than the GdkDevice business.
2016-04-04 10:21:54 +00:00
#if GTK_CHECK_VERSION(3,20,0)
GdkSeat *seat; /* for gdk_seat_grab */
#elif GTK_CHECK_VERSION(3,0,0)
GTK3 port: use gdk_device_grab() in gtkask.c. This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has to use for grabbing the keyboard away from all other X clients.
2015-08-16 13:36:32 +00:00
GdkDevice *keyboard; /* for gdk_device_grab */
#endif
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
int nattempts;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
};
Use a proper PRNG for GTK askpass. Coverity complained that it was wrong to use rand() in a security context, and although in this case it's _very_ marginal, I can't actually disagree that the choice of which light to light up to avoid giving information about passphrase length is a security context. So, no more rand(); instead we instantiate a shiny Fortuna PRNG instance, seed it in more or less the usual way, and use that as an overkill-level method of choosing which light to light up next. (Acknowledging that this is a slightly unusual application and less critical than most, I don't actually put the passphrase characters themselves into the PRNG, and I don't use a random-seed file.)
2019-05-05 19:22:36 +00:00
static prng *keypress_prng = NULL;
static void feed_keypress_prng(void *data, int size)
{
put_data(keypress_prng, data, size);
}
void random_add_noise(NoiseSourceId source, const void *noise, int length)
{
if (keypress_prng)
prng_add_entropy(keypress_prng, source, make_ptrlen(noise, length));
}
static void setup_keypress_prng(void)
{
keypress_prng = prng_new(&ssh_sha256);
prng_seed_begin(keypress_prng);
noise_get_heavy(feed_keypress_prng);
prng_seed_finish(keypress_prng);
}
static void cleanup_keypress_prng(void)
{
prng_free(keypress_prng);
}
gtkask.c: use dedicated PRNG for initial area choice. At Coverity's urging, I put in an instance of the Fortuna PRNG in place of the use of rand() to select which drawing area to light up next on a keypress. But Coverity turns out to be unhappy that I'm still using rand() to select the _initial_ area, before the user enters any input at all. It's even harder to imagine this being a genuine information leak than the previous complaint. But I don't really see a reason _not_ to switch it over, now it's been pointed out.
2019-07-23 17:40:09 +00:00
static uint64_t keypress_prng_value(void)
Use a proper PRNG for GTK askpass. Coverity complained that it was wrong to use rand() in a security context, and although in this case it's _very_ marginal, I can't actually disagree that the choice of which light to light up to avoid giving information about passphrase length is a security context. So, no more rand(); instead we instantiate a shiny Fortuna PRNG instance, seed it in more or less the usual way, and use that as an overkill-level method of choosing which light to light up next. (Acknowledging that this is a slightly unusual application and less critical than most, I don't actually put the passphrase characters themselves into the PRNG, and I don't use a random-seed file.)
2019-05-05 19:22:36 +00:00
{
Missing piece of the previous commit. Ahem. I was sure I'd hit save!
2019-05-05 19:43:16 +00:00
/*
* Don't actually put the passphrase keystrokes themselves into
* the PRNG; that doesn't seem like the course of wisdom when
* that's precisely what the information displayed on the screen
* is trying _not_ to be correlated to.
*/
noise_ultralight(NOISE_SOURCE_KEY, 0);
Use a proper PRNG for GTK askpass. Coverity complained that it was wrong to use rand() in a security context, and although in this case it's _very_ marginal, I can't actually disagree that the choice of which light to light up to avoid giving information about passphrase length is a security context. So, no more rand(); instead we instantiate a shiny Fortuna PRNG instance, seed it in more or less the usual way, and use that as an overkill-level method of choosing which light to light up next. (Acknowledging that this is a slightly unusual application and less critical than most, I don't actually put the passphrase characters themselves into the PRNG, and I don't use a random-seed file.)
2019-05-05 19:22:36 +00:00
uint8_t data[8];
prng_read(keypress_prng, data, 8);
gtkask.c: use dedicated PRNG for initial area choice. At Coverity's urging, I put in an instance of the Fortuna PRNG in place of the use of rand() to select which drawing area to light up next on a keypress. But Coverity turns out to be unhappy that I'm still using rand() to select the _initial_ area, before the user enters any input at all. It's even harder to imagine this being a genuine information leak than the previous complaint. But I don't really see a reason _not_ to switch it over, now it's been pointed out.
2019-07-23 17:40:09 +00:00
return GET_64BIT_MSB_FIRST(data);
}
static int choose_new_area(int prev_area)
{
int reduced = keypress_prng_value() % (N_DRAWING_AREAS - 1);
Use a proper PRNG for GTK askpass. Coverity complained that it was wrong to use rand() in a security context, and although in this case it's _very_ marginal, I can't actually disagree that the choice of which light to light up to avoid giving information about passphrase length is a security context. So, no more rand(); instead we instantiate a shiny Fortuna PRNG instance, seed it in more or less the usual way, and use that as an overkill-level method of choosing which light to light up next. (Acknowledging that this is a slightly unusual application and less critical than most, I don't actually put the passphrase characters themselves into the PRNG, and I don't use a random-seed file.)
2019-05-05 19:22:36 +00:00
return (prev_area + 1 + reduced) % N_DRAWING_AREAS;
}
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
static void visually_acknowledge_keypress(struct askpass_ctx *ctx)
{
Use a proper PRNG for GTK askpass. Coverity complained that it was wrong to use rand() in a security context, and although in this case it's _very_ marginal, I can't actually disagree that the choice of which light to light up to avoid giving information about passphrase length is a security context. So, no more rand(); instead we instantiate a shiny Fortuna PRNG instance, seed it in more or less the usual way, and use that as an overkill-level method of choosing which light to light up next. (Acknowledging that this is a slightly unusual application and less critical than most, I don't actually put the passphrase characters themselves into the PRNG, and I don't use a random-seed file.)
2019-05-05 19:22:36 +00:00
int new_active = choose_new_area(ctx->active_area);
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
ctx->drawingareas[ctx->active_area].state = NOT_CURRENT;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
gtk_widget_queue_draw(ctx->drawingareas[ctx->active_area].area);
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
ctx->drawingareas[new_active].state = CURRENT;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
gtk_widget_queue_draw(ctx->drawingareas[new_active].area);
ctx->active_area = new_active;
}
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
static size_t last_char_start(struct askpass_ctx *ctx)
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
{
/*
* GTK always encodes in UTF-8, so we can do this in a fixed way.
*/
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
assert(ctx->passphrase->len > 0);
size_t i = ctx->passphrase->len - 1;
while ((unsigned)(ctx->passphrase->u[i] - 0x80) < 0x40) {
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
if (i == 0)
break;
i--;
}
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
return i;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
}
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
static void add_text_to_passphrase(struct askpass_ctx *ctx, gchar *str)
{
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
put_datapl(ctx->passphrase, ptrlen_from_asciz(str));
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
visually_acknowledge_keypress(ctx);
}
Unix pageant: handle askpass dialog close button. Treat as aborting passphrase input. (Previously it would just hang.)
2021-04-05 16:48:30 +00:00
static void cancel_askpass(struct askpass_ctx *ctx, const char *msg)
{
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
strbuf_free(ctx->passphrase);
Unix pageant: handle askpass dialog close button. Treat as aborting passphrase input. (Previously it would just hang.)
2021-04-05 16:48:30 +00:00
ctx->passphrase = NULL;
ctx->error_message = dupstr(msg);
gtk_main_quit();
}
static gboolean askpass_dialog_closed(GtkWidget *widget, GdkEvent *event,
gpointer data)
{
struct askpass_ctx *ctx = (struct askpass_ctx *)data;
cancel_askpass(ctx, "passphrase input cancelled");
/* Don't destroy dialog yet, so gtk_askpass_cleanup() can do its work */
return true;
}
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
static gint key_event(GtkWidget *widget, GdkEventKey *event, gpointer data)
{
struct askpass_ctx *ctx = (struct askpass_ctx *)data;
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
GTK 3 prep: use GDK_KEY_<keyname> constants, not GDK_<keyname>. GTK 2 doesn't _documentedly_ provide a helpful compile option to let us check this one in advance of GTK 3, but you can fake one anyway by compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h will believe that it's already been included :-) We now build cleanly under GTK 2 with that predefine.
2015-08-08 15:23:54 +00:00
if (event->keyval == GDK_KEY_Return &&
event->type == GDK_KEY_PRESS) {
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
gtk_main_quit();
GTK 3 prep: use GDK_KEY_<keyname> constants, not GDK_<keyname>. GTK 2 doesn't _documentedly_ provide a helpful compile option to let us check this one in advance of GTK 3, but you can fake one anyway by compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h will believe that it's already been included :-) We now build cleanly under GTK 2 with that predefine.
2015-08-08 15:23:54 +00:00
} else if (event->keyval == GDK_KEY_Escape &&
event->type == GDK_KEY_PRESS) {
Unix pageant: handle askpass dialog close button. Treat as aborting passphrase input. (Previously it would just hang.)
2021-04-05 16:48:30 +00:00
cancel_askpass(ctx, "passphrase input cancelled");
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
} else {
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
if (gtk_im_context_filter_keypress(ctx->imc, event))
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;
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
#endif
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
if (event->type == GDK_KEY_PRESS) {
if (!strcmp(event->string, "\x15")) {
/* Ctrl-U. Wipe out the whole line */
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
strbuf_clear(ctx->passphrase);
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
visually_acknowledge_keypress(ctx);
} else if (!strcmp(event->string, "\x17")) {
/* Ctrl-W. Delete back to the last space->nonspace
* boundary. We interpret 'space' in a really simple
* way (mimicking terminal drivers), and don't attempt
* to second-guess exciting Unicode space
* characters. */
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
while (ctx->passphrase->len > 0) {
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
char deleted, prior;
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
size_t newlen = last_char_start(ctx);
deleted = ctx->passphrase->s[newlen];
strbuf_shrink_to(ctx->passphrase, newlen);
prior = (ctx->passphrase->len == 0 ? ' ' :
ctx->passphrase->s[ctx->passphrase->len-1]);
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
if (!g_ascii_isspace(deleted) && g_ascii_isspace(prior))
break;
}
visually_acknowledge_keypress(ctx);
GTK 3 prep: use GDK_KEY_<keyname> constants, not GDK_<keyname>. GTK 2 doesn't _documentedly_ provide a helpful compile option to let us check this one in advance of GTK 3, but you can fake one anyway by compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h will believe that it's already been included :-) We now build cleanly under GTK 2 with that predefine.
2015-08-08 15:23:54 +00:00
} else if (event->keyval == GDK_KEY_BackSpace) {
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
/* Backspace. Delete one character. */
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
if (ctx->passphrase->len > 0)
strbuf_shrink_to(ctx->passphrase, last_char_start(ctx));
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
visually_acknowledge_keypress(ctx);
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
} else if (event->string[0]) {
add_text_to_passphrase(ctx, event->string);
#endif
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
}
}
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
}
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
static void input_method_commit_event(GtkIMContext *imc, gchar *str,
gpointer data)
{
struct askpass_ctx *ctx = (struct askpass_ctx *)data;
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
add_text_to_passphrase(ctx, str);
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
}
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
#endif
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
static gint configure_area(GtkWidget *widget, GdkEventConfigure *event,
gpointer data)
{
struct drawing_area_ctx *ctx = (struct drawing_area_ctx *)data;
ctx->width = event->width;
ctx->height = event->height;
gtk_widget_queue_draw(widget);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
}
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
#ifdef DRAW_DEFAULT_CAIRO
static void askpass_redraw_cairo(cairo_t *cr, struct drawing_area_ctx *ctx)
{
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
double rgbval = (ctx->state == CURRENT ? 0 :
ctx->state == NOT_CURRENT ? 1 : 0.5);
cairo_set_source_rgb(cr, rgbval, rgbval, rgbval);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
cairo_paint(cr);
}
#else
static void askpass_redraw_gdk(GdkWindow *win, struct drawing_area_ctx *ctx)
{
GdkGC *gc = gdk_gc_new(win);
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
gdk_gc_set_foreground(gc, &ctx->cols[ctx->state]);
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
gdk_draw_rectangle(win, gc, true, 0, 0, ctx->width, ctx->height);
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
gdk_gc_unref(gc);
}
#endif
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
#if GTK_CHECK_VERSION(3,0,0)
static gint draw_area(GtkWidget *widget, cairo_t *cr, gpointer data)
{
struct drawing_area_ctx *ctx = (struct drawing_area_ctx *)data;
askpass_redraw_cairo(cr, ctx);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
}
#else
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
static gint expose_area(GtkWidget *widget, GdkEventExpose *event,
gpointer data)
{
struct drawing_area_ctx *ctx = (struct drawing_area_ctx *)data;
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
#ifdef DRAW_DEFAULT_CAIRO
cairo_t *cr = gdk_cairo_create(gtk_widget_get_window(ctx->area));
askpass_redraw_cairo(cr, ctx);
cairo_destroy(cr);
#else
askpass_redraw_gdk(gtk_widget_get_window(ctx->area), ctx);
#endif
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
}
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
#endif
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
static gboolean try_grab_keyboard(gpointer vctx)
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
{
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
struct askpass_ctx *ctx = (struct askpass_ctx *)vctx;
int i, ret;
GTK3 port: use gdk_device_grab() in gtkask.c. This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has to use for grabbing the keyboard away from all other X clients.
2015-08-16 13:36:32 +00:00
GTK 3.20 compatibility: switch to gdk_seat_grab. gdk_device_grab and all its preparatory faff are now deprecated, and gdk_seat_grab is the new thing. Introduce yet another branch to all the ifdefs for keyboard-grabbing. On the plus side, at least it's slightly simpler than the GdkDevice business.
2016-04-04 10:21:54 +00:00
#if GTK_CHECK_VERSION(3,20,0)
GTK3 port: use gdk_device_grab() in gtkask.c. This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has to use for grabbing the keyboard away from all other X clients.
2015-08-16 13:36:32 +00:00
/*
GTK 3.20 compatibility: switch to gdk_seat_grab. gdk_device_grab and all its preparatory faff are now deprecated, and gdk_seat_grab is the new thing. Introduce yet another branch to all the ifdefs for keyboard-grabbing. On the plus side, at least it's slightly simpler than the GdkDevice business.
2016-04-04 10:21:54 +00:00
* Grabbing the keyboard in GTK 3.20 requires the new notion of
* GdkSeat.
*/
GdkSeat *seat;
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
GdkWindow *gdkw = gtk_widget_get_window(ctx->dialog);
if (!GDK_IS_WINDOW(gdkw) || !gdk_window_is_visible(gdkw))
goto fail;
GTK 3.20 compatibility: switch to gdk_seat_grab. gdk_device_grab and all its preparatory faff are now deprecated, and gdk_seat_grab is the new thing. Introduce yet another branch to all the ifdefs for keyboard-grabbing. On the plus side, at least it's slightly simpler than the GdkDevice business.
2016-04-04 10:21:54 +00:00
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
seat = gdk_display_get_default_seat(
gtk_widget_get_display(ctx->dialog));
GTK 3.20 compatibility: switch to gdk_seat_grab. gdk_device_grab and all its preparatory faff are now deprecated, and gdk_seat_grab is the new thing. Introduce yet another branch to all the ifdefs for keyboard-grabbing. On the plus side, at least it's slightly simpler than the GdkDevice business.
2016-04-04 10:21:54 +00:00
if (!seat)
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
goto fail;
GTK 3.20 compatibility: switch to gdk_seat_grab. gdk_device_grab and all its preparatory faff are now deprecated, and gdk_seat_grab is the new thing. Introduce yet another branch to all the ifdefs for keyboard-grabbing. On the plus side, at least it's slightly simpler than the GdkDevice business.
2016-04-04 10:21:54 +00:00
ctx->seat = seat;
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
ret = gdk_seat_grab(seat, gdkw, GDK_SEAT_CAPABILITY_KEYBOARD,
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
true, NULL, NULL, NULL, NULL);
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
/*
* For some reason GDK 3.22 hides the GDK window as a side effect
* of a failed grab. I've no idea why. But if we're going to retry
* the grab, then we need to unhide it again or else we'll just
* get GDK_GRAB_NOT_VIEWABLE on every subsequent attempt.
*/
if (ret != GDK_GRAB_SUCCESS)
gdk_window_show(gdkw);
GTK 3.20 compatibility: switch to gdk_seat_grab. gdk_device_grab and all its preparatory faff are now deprecated, and gdk_seat_grab is the new thing. Introduce yet another branch to all the ifdefs for keyboard-grabbing. On the plus side, at least it's slightly simpler than the GdkDevice business.
2016-04-04 10:21:54 +00:00
#elif GTK_CHECK_VERSION(3,0,0)
/*
* And it has to be done differently again prior to GTK 3.20.
GTK3 port: use gdk_device_grab() in gtkask.c. This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has to use for grabbing the keyboard away from all other X clients.
2015-08-16 13:36:32 +00:00
*/
GdkDeviceManager *dm;
GdkDevice *pointer, *keyboard;
Formatting: standardise on "func(\n", not "func\n(". If the function name (or expression) in a function call or declaration is itself so long that even the first argument doesn't fit after it on the same line, or if that would leave so little space that it would be silly to try to wrap all the run-on lines into a tall thin column, then I used to do this ludicrously_long_function_name (arg1, arg2, arg3); and now prefer this ludicrously_long_function_name( arg1, arg2, arg3); I picked up the habit from Python, where the latter idiom is required by Python's syntactic significance of newlines (you can write the former if you use a backslash-continuation, but pretty much everyone seems to agree that that's much uglier). But I've found it works well in C as well: it makes it more obvious that the previous line is incomplete, it gives you a tiny bit more space to wrap the following lines into (the old idiom indents the _third_ line one space beyond the second), and I generally turn out to agree with the knock-on indentation decisions made by at least Emacs if you do it in the middle of a complex expression. Plus, of course, using the _same_ idiom between C and Python means less state-switching. So, while I'm making annoying indentation changes in general, this seems like a good time to dig out all the cases of the old idiom in this code, and switch them over to the new.
2022-08-03 19:48:46 +00:00
dm = gdk_display_get_device_manager(
gtk_widget_get_display(ctx->dialog));
GTK3 port: use gdk_device_grab() in gtkask.c. This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has to use for grabbing the keyboard away from all other X clients.
2015-08-16 13:36:32 +00:00
if (!dm)
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
goto fail;
GTK3 port: use gdk_device_grab() in gtkask.c. This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has to use for grabbing the keyboard away from all other X clients.
2015-08-16 13:36:32 +00:00
pointer = gdk_device_manager_get_client_pointer(dm);
if (!pointer)
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
goto fail;
GTK3 port: use gdk_device_grab() in gtkask.c. This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has to use for grabbing the keyboard away from all other X clients.
2015-08-16 13:36:32 +00:00
keyboard = gdk_device_get_associated_device(pointer);
if (!keyboard)
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
goto fail;
GTK3 port: use gdk_device_grab() in gtkask.c. This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has to use for grabbing the keyboard away from all other X clients.
2015-08-16 13:36:32 +00:00
if (gdk_device_get_source(keyboard) != GDK_SOURCE_KEYBOARD)
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
goto fail;
GTK3 port: use gdk_device_grab() in gtkask.c. This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has to use for grabbing the keyboard away from all other X clients.
2015-08-16 13:36:32 +00:00
ctx->keyboard = keyboard;
ret = gdk_device_grab(ctx->keyboard,
gtk_widget_get_window(ctx->dialog),
GDK_OWNERSHIP_NONE,
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
true,
GTK3 port: use gdk_device_grab() in gtkask.c. This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has to use for grabbing the keyboard away from all other X clients.
2015-08-16 13:36:32 +00:00
GDK_KEY_PRESS_MASK | GDK_KEY_RELEASE_MASK,
NULL,
GDK_CURRENT_TIME);
#else
/*
* It's much simpler in GTK 1 and 2!
*/
ret = gdk_keyboard_grab(gtk_widget_get_window(ctx->dialog),
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
false, GDK_CURRENT_TIME);
GTK3 port: use gdk_device_grab() in gtkask.c. This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has to use for grabbing the keyboard away from all other X clients.
2015-08-16 13:36:32 +00:00
#endif
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
if (ret != GDK_GRAB_SUCCESS)
goto fail;
GTK3 port: use gdk_device_grab() in gtkask.c. This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has to use for grabbing the keyboard away from all other X clients.
2015-08-16 13:36:32 +00:00
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
/*
* Now that we've got the keyboard grab, connect up our keyboard
* handlers.
*/
#if GTK_CHECK_VERSION(2,0,0)
g_signal_connect(G_OBJECT(ctx->imc), "commit",
G_CALLBACK(input_method_commit_event), ctx);
#endif
g_signal_connect(G_OBJECT(ctx->dialog), "key_press_event",
G_CALLBACK(key_event), ctx);
g_signal_connect(G_OBJECT(ctx->dialog), "key_release_event",
G_CALLBACK(key_event), ctx);
#if GTK_CHECK_VERSION(2,0,0)
gtk_im_context_set_client_window(ctx->imc,
gtk_widget_get_window(ctx->dialog));
#endif
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
/*
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
* And repaint the key-acknowledgment drawing areas as not greyed
* out.
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
*/
gtkask.c: use dedicated PRNG for initial area choice. At Coverity's urging, I put in an instance of the Fortuna PRNG in place of the use of rand() to select which drawing area to light up next on a keypress. But Coverity turns out to be unhappy that I'm still using rand() to select the _initial_ area, before the user enters any input at all. It's even harder to imagine this being a genuine information leak than the previous complaint. But I don't really see a reason _not_ to switch it over, now it's been pointed out.
2019-07-23 17:40:09 +00:00
ctx->active_area = keypress_prng_value() % N_DRAWING_AREAS;
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
for (i = 0; i < N_DRAWING_AREAS; i++) {
ctx->drawingareas[i].state =
(i == ctx->active_area ? CURRENT : NOT_CURRENT);
gtk_widget_queue_draw(ctx->drawingareas[i].area);
}
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
fail:
/*
* If we didn't get the grab, reschedule ourself on a timer to try
* again later.
*
* We have to do this rather than just trying once, because there
* is at least one important situation in which the grab may fail
* the first time: any user who is launching an add-key operation
* off some kind of window manager hotkey will almost by
* definition be running this script with a keyboard grab already
* active, namely the one-key grab that the WM (or whatever) uses
* to detect presses of the hotkey. So at the very least we have
* to give the user time to release that key.
*/
if (++ctx->nattempts >= 4) {
Unix pageant: handle askpass dialog close button. Treat as aborting passphrase input. (Previously it would just hang.)
2021-04-05 16:48:30 +00:00
cancel_askpass(ctx, "unable to grab keyboard after 5 seconds");
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
} else {
g_timeout_add(1000/8, try_grab_keyboard, ctx);
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
}
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
void realize(GtkWidget *widget, gpointer vctx)
{
struct askpass_ctx *ctx = (struct askpass_ctx *)vctx;
gtk_grab_add(ctx->dialog);
/*
* Schedule the first attempt at the keyboard grab.
*/
ctx->nattempts = 0;
#if GTK_CHECK_VERSION(3,20,0)
ctx->seat = NULL;
#elif GTK_CHECK_VERSION(3,0,0)
ctx->keyboard = NULL;
#endif
g_idle_add(try_grab_keyboard, ctx);
}
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
static const char *gtk_askpass_setup(struct askpass_ctx *ctx,
const char *window_title,
const char *prompt_text)
{
int i;
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
GtkBox *action_area;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
ctx->passphrase = strbuf_new_nm();
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
/*
* Create widgets.
*/
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
ctx->dialog = our_dialog_new();
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
gtk_window_set_title(GTK_WINDOW(ctx->dialog), window_title);
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
gtk_window_set_position(GTK_WINDOW(ctx->dialog), GTK_WIN_POS_CENTER);
Unix pageant: handle askpass dialog close button. Treat as aborting passphrase input. (Previously it would just hang.)
2021-04-05 16:48:30 +00:00
g_signal_connect(G_OBJECT(ctx->dialog), "delete-event",
Formatting: realign run-on parenthesised stuff. My bulk indentation check also turned up a lot of cases where a run-on function call or if statement didn't have its later lines aligned correctly relative to the open paren. I think this is quite easy to do by getting things out of sync (editing the first line of the function call and forgetting to update the rest, perhaps even because you never _saw_ the rest during a search-replace). But a few didn't quite fit into that pattern, in particular an outright misleading case in unix/askpass.c where the second line of a call was aligned neatly below the _wrong_ one of the open parens on the opening line. Restored as many alignments as I could easily find.
2022-08-03 19:48:46 +00:00
G_CALLBACK(askpass_dialog_closed), ctx);
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
ctx->promptlabel = gtk_label_new(prompt_text);
Slightly improve layout in GTK3 Pageant passphrase prompts. Now I've moved align_label_left() into gtkmisc.c where gtkask.c can get at it, we can use it to fix the alignment of the prompt label. Also, use gtk_label_set_width_chars() to give the label a more or less sensible width.
2015-08-31 14:45:27 +00:00
align_label_left(GTK_LABEL(ctx->promptlabel));
Don't defer displaying the prompt label in gtkask. The previous sequence of events was that I would display the window synchronously (via gtk_widget_show_now), so that I knew it was actually on the screen and realised as an X window, and then I'd grab the keyboard, and once the keyboard was grabbed, connect up the keyboard event handlers and display the prompt. I have to assume that deferring the display of the 'enter the passphrase' prompt until the keyboard handlers were set up was intended as some sort of 'not misleading the user' measure - don't tell them to start typing until we're actually ready to start typing. But unfortunately it has the side effect that the window is displayed at a much smaller size before the prompt label appears, and centred on the screen according to _that_ size - and then we display the prompt label and the window resizes and is now off-centre. So I think it's better not to try to be clever, and just make the window come up at the right size initially. (Actually, it looks as if nothing in the window is actually drawn until that whole init function is finished anyway, so the prompt label _already_ doesn't get physically displayed too early. So the whole idea was pointless in the first place!)
2015-09-26 10:09:20 +00:00
gtk_widget_show(ctx->promptlabel);
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
gtk_label_set_line_wrap(GTK_LABEL(ctx->promptlabel), true);
Slightly improve layout in GTK3 Pageant passphrase prompts. Now I've moved align_label_left() into gtkmisc.c where gtkask.c can get at it, we can use it to fix the alignment of the prompt label. Also, use gtk_label_set_width_chars() to give the label a more or less sensible width.
2015-08-31 14:45:27 +00:00
#if GTK_CHECK_VERSION(3,0,0)
gtk_label_set_width_chars(GTK_LABEL(ctx->promptlabel), 48);
gtk-askpass: add margins on left and right of the prompt. If the prompt got big enough to reach to the edges of the dialog box, it looked ugly without any margins. Previously I hadn't noticed, because the prompt text was never that big.
2021-04-02 11:54:52 +00:00
#endif
int margin = string_width("MM");
#if GTK_CHECK_VERSION(3,12,0)
gtk_widget_set_margin_start(ctx->promptlabel, margin);
gtk_widget_set_margin_end(ctx->promptlabel, margin);
#else
gtk_misc_set_padding(GTK_MISC(ctx->promptlabel), margin, 0);
Slightly improve layout in GTK3 Pageant passphrase prompts. Now I've moved align_label_left() into gtkmisc.c where gtkask.c can get at it, we can use it to fix the alignment of the prompt label. Also, use gtk_label_set_width_chars() to give the label a more or less sensible width.
2015-08-31 14:45:27 +00:00
#endif
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
our_dialog_add_to_content_area(GTK_WINDOW(ctx->dialog),
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
ctx->promptlabel, true, true, 0);
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
ctx->imc = gtk_im_multicontext_new();
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
#endif
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
#ifndef DRAW_DEFAULT_CAIRO
{
gboolean success[2];
ctx->colmap = gdk_colormap_get_system();
ctx->cols[0].red = ctx->cols[0].green = ctx->cols[0].blue = 0xFFFF;
ctx->cols[1].red = ctx->cols[1].green = ctx->cols[1].blue = 0;
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
ctx->cols[2].red = ctx->cols[2].green = ctx->cols[2].blue = 0x8000;
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
gdk_colormap_alloc_colors(ctx->colmap, ctx->cols, 2,
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
false, true, success);
Remove three uses of bitwise ops on boolean values. If values are boolean, it's confusing to use & and | in place of && and ||. In two of these three cases it was simply a typo and I've used the other one; in the third, it was a deliberate avoidance of short- circuit evaluation (and commented as such), but having seen how easy it is to make the same typo by accident, I've decided it's clearer to just move the LHS and RHS evaluations outside the expression.
2018-10-30 18:09:12 +00:00
if (!success[0] || !success[1])
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
return "unable to allocate colours";
}
#endif
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
action_area = our_dialog_make_action_hbox(GTK_WINDOW(ctx->dialog));
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
for (i = 0; i < N_DRAWING_AREAS; i++) {
ctx->drawingareas[i].area = gtk_drawing_area_new();
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
#ifndef DRAW_DEFAULT_CAIRO
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
ctx->drawingareas[i].cols = ctx->cols;
Refactor the GTK drawing system to do both GDK and Cairo. We're going to have to use Cairo in the GTK3 port, because that's all GTK3 supports; but we still need old-style GDK for GTK1 support, and also for performance reasons in GTK2 (see below). Hence, this change completely restructures GTK PuTTY's drawing code so that there's a central 'drawing context' structure which contains a type code indicating GDK or Cairo, and then either some GDK gubbins or some Cairo gubbins as appropriate; all actual drawing is abstracted through a set of routines which test the type code in that structure and do one thing or another. And because the type code is tested at run time, both sets of drawing primitives can be compiled in at once, and where possible, they will be. X server-side bitmap fonts are still supported in the Cairo world, but because Cairo drawing is entirely client-side, they have to work by cheekily downloading each glyph bitmap from the server when it's first needed, and building up a client-side cache of 'cairo_surface_t's containing the bitmaps with which we then draw on the window. This technique works, but it's rather slow; hence, even in GTK2, we keep the GDK drawing back end compiled in, and switch over to it when the main selected font is a bitmap one. One visible effect of the new Cairo routines is in the double-width and double-height text you can get by sending ESC # 3, ESC # 4 and ESC # 6 escape sequences. In GDK, that's always been done by a really horrible process of manually scaling the bitmap, server-side, column by column and row by row, causing each pixel to be exactly doubled or quadrupled. But in Cairo, we can just set a transformation matrix, and then that takes effect _before_ the scalable fonts are rendered - so the results are visibly nicer, and use all the available resolution. (Sadly, if you're using a server-side bitmap font as your primary one, then the GDK backend will be selected for all drawing in the terminal as a whole - so in that situation, even fallback characters absent from the primary font and rendered by Pango will get the old GDK scaling treatment. It's only if your main font is scalable, so that the Cairo backend is selected, that DW/DH characters will come out looking nice.)
2015-08-15 20:05:56 +00:00
#endif
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
ctx->drawingareas[i].state = GREYED_OUT;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
ctx->drawingareas[i].width = ctx->drawingareas[i].height = 0;
/* It would be nice to choose this size in some more
* context-sensitive way, like measuring the size of some
* piece of template text. */
gtk_widget_set_size_request(ctx->drawingareas[i].area, 32, 32);
Stop using GtkDialog (for most purposes) in GTK 3! They've now deprecated gtk_dialog_get_action_area, because they really want a dialog box's action area to be filled with nothing but buttons controlled by GTK which end the dialog with a response code. But we're accustomed to putting all sorts of other things in our action area - non-buttons, buttons that don't end the dialog, and sub-widgets that do layout - and so I think it's no longer sensible to be trying to coerce our use cases into GtkDialog. Hence, I'm introducing a set of wrapper functions which equivocate between a GtkDialog for GTK1 and GTK2, and a GtkWindow with a vbox in it for GTK3, and I'll lay out the action area by hand. (Not everything has sensible layout and margins in the new GTK3 system yet, but I can sort that out later.) Because the new functions are needed by gtkask.c, which doesn't link against gtkdlg.c or include putty.h, I've put them in a new source file and header file pair gtkmisc.[ch] which is common to gtkask and the main GTK edifice.
2015-08-31 14:45:18 +00:00
gtk_box_pack_end(action_area, ctx->drawingareas[i].area,
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
true, true, 5);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(ctx->drawingareas[i].area),
"configure_event",
G_CALLBACK(configure_area),
&ctx->drawingareas[i]);
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
#if GTK_CHECK_VERSION(3,0,0)
g_signal_connect(G_OBJECT(ctx->drawingareas[i].area),
"draw",
G_CALLBACK(draw_area),
&ctx->drawingareas[i]);
#else
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
g_signal_connect(G_OBJECT(ctx->drawingareas[i].area),
"expose_event",
G_CALLBACK(expose_area),
&ctx->drawingareas[i]);
GTK3 port: support the new "draw" signal. This replaces GTK 1/2's "expose_event", and provides a ready-made cairo_t to do the drawing with. My previous work has already separated all constructions of a cairo_t from the subsequent drawing with it, so the new draw event handlers just have to call the latter without the former.
2015-08-16 13:34:19 +00:00
#endif
GTK 3: tweak margin below the gtkask drawing areas. A side effect of commit 1f9df706b seems to have been to squash those areas right up against the bottom of the dialog box, which is ugly. I don't fully understand why it only happens to those drawing areas and not to buttons placed in the fake 'action area' by other dialogs, but anyway, adding an explicit margin-bottom attribute seems to solve it.
2016-04-04 10:49:05 +00:00
#if GTK_CHECK_VERSION(3,0,0)
g_object_set(G_OBJECT(ctx->drawingareas[i].area),
"margin-bottom", 8, (const char *)NULL);
#endif
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
gtk_widget_show(ctx->drawingareas[i].area);
}
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
ctx->active_area = -1;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
/*
* Arrange to receive key events. We don't really need to worry
* from a UI perspective about which widget gets the events, as
* long as we know which it is so we can catch them. So we'll pick
* the prompt label at random, and we'll use gtk_grab_add to
* ensure key events go to it.
*/
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
gtk_widget_set_sensitive(ctx->dialog, true);
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
#if GTK_CHECK_VERSION(2,0,0)
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_window_set_keep_above(GTK_WINDOW(ctx->dialog), true);
Make gtkask.c compile under GTK 1. This is less than ideal - passphrase input now happens in ISO 8859-1, and the passphrase prompt window is neither centred nor always-on-top. But it basically works, and restores bare-minimum GTK 1 support to the codebase as a whole.
2015-08-08 14:04:28 +00:00
#endif
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
/*
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
* Wait for the key-receiving widget to actually be created, in
* order to call gtk_grab_add on it.
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
*/
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
g_signal_connect(G_OBJECT(ctx->dialog), "realize",
G_CALLBACK(realize), ctx);
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
/*
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
* Show the window.
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
*/
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
gtk_widget_show(ctx->dialog);
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
return NULL;
}
static void gtk_askpass_cleanup(struct askpass_ctx *ctx)
{
GTK 3.20 compatibility: switch to gdk_seat_grab. gdk_device_grab and all its preparatory faff are now deprecated, and gdk_seat_grab is the new thing. Introduce yet another branch to all the ifdefs for keyboard-grabbing. On the plus side, at least it's slightly simpler than the GdkDevice business.
2016-04-04 10:21:54 +00:00
#if GTK_CHECK_VERSION(3,20,0)
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
if (ctx->seat)
gdk_seat_ungrab(ctx->seat);
GTK 3.20 compatibility: switch to gdk_seat_grab. gdk_device_grab and all its preparatory faff are now deprecated, and gdk_seat_grab is the new thing. Introduce yet another branch to all the ifdefs for keyboard-grabbing. On the plus side, at least it's slightly simpler than the GdkDevice business.
2016-04-04 10:21:54 +00:00
#elif GTK_CHECK_VERSION(3,0,0)
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
if (ctx->keyboard)
gdk_device_ungrab(ctx->keyboard, GDK_CURRENT_TIME);
GTK3 port: use gdk_device_grab() in gtkask.c. This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has to use for grabbing the keyboard away from all other X clients.
2015-08-16 13:36:32 +00:00
#else
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
gdk_keyboard_ungrab(GDK_CURRENT_TIME);
GTK3 port: use gdk_device_grab() in gtkask.c. This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has to use for grabbing the keyboard away from all other X clients.
2015-08-16 13:36:32 +00:00
#endif
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
gtk_grab_remove(ctx->promptlabel);
gtk_widget_destroy(ctx->dialog);
}
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 setup_gtk(const char *display)
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
{
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 gtk_initialised = false;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
int argc;
char *real_argv[3];
char **argv = real_argv;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool ret;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
if (gtk_initialised)
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return true;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
argc = 0;
argv[argc++] = dupstr("dummy");
argv[argc++] = dupprintf("--display=%s", display);
argv[argc] = NULL;
ret = gtk_init_check(&argc, &argv);
while (argc > 0)
sfree(argv[--argc]);
gtk_initialised = ret;
return ret;
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
const bool buildinfo_gtk_relevant = true;
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
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
char *gtk_askpass_main(const char *display, const char *wintitle,
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 char *prompt, bool *success)
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
{
Refactor 'struct context *ctx = &actx' pattern. When I'm declaring a local instance of some context structure type to pass to a function which will pass it in turn to a callback, I've tended to use a declaration of the form struct context actx, *ctx = &actx; so that the outermost caller can initialise the context, and/or read out fields of it afterwards, by the same syntax 'ctx->foo' that the callback function will be using. So you get visual consistency between the two functions that share this context. It only just occurred to me that there's a much neater way to declare a context struct of this kind, which still makes 'ctx' behave like a pointer in the owning function, and doesn't need all that weird verbiage or a spare variable name: struct context ctx[1]; That's much nicer! I've switched to doing that in all existing cases I could find, and also in a couple of cases where I hadn't previously bothered to do the previous more cumbersome idiom.
2019-12-22 08:15:52 +00:00
struct askpass_ctx ctx[1];
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
const char *err;
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
ctx->passphrase = NULL;
ctx->error_message = NULL;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
/* In case gtk_init hasn't been called yet by the program */
if (!setup_gtk(display)) {
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
*success = false;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
return dupstr("unable to initialise GTK");
}
if ((err = gtk_askpass_setup(ctx, wintitle, prompt)) != NULL) {
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
*success = false;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
return dupprintf("%s", err);
}
Use a proper PRNG for GTK askpass. Coverity complained that it was wrong to use rand() in a security context, and although in this case it's _very_ marginal, I can't actually disagree that the choice of which light to light up to avoid giving information about passphrase length is a security context. So, no more rand(); instead we instantiate a shiny Fortuna PRNG instance, seed it in more or less the usual way, and use that as an overkill-level method of choosing which light to light up next. (Acknowledging that this is a slightly unusual application and less critical than most, I don't actually put the passphrase characters themselves into the PRNG, and I don't use a random-seed file.)
2019-05-05 19:22:36 +00:00
setup_keypress_prng();
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
gtk_main();
Use a proper PRNG for GTK askpass. Coverity complained that it was wrong to use rand() in a security context, and although in this case it's _very_ marginal, I can't actually disagree that the choice of which light to light up to avoid giving information about passphrase length is a security context. So, no more rand(); instead we instantiate a shiny Fortuna PRNG instance, seed it in more or less the usual way, and use that as an overkill-level method of choosing which light to light up next. (Acknowledging that this is a slightly unusual application and less critical than most, I don't actually put the passphrase characters themselves into the PRNG, and I don't use a random-seed file.)
2019-05-05 19:22:36 +00:00
cleanup_keypress_prng();
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
gtk_askpass_cleanup(ctx);
if (ctx->passphrase) {
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
*success = true;
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
return strbuf_to_str(ctx->passphrase);
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
} else {
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
*success = false;
gtkask: rework the mechanism for keyboard grabs. I've found Unix Pageant's GTK password prompt to be a bit flaky on Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that GTK has changed its internal order of setting things up, so that you can no longer call gtk_widget_show_now() and expect that when it returns everything is ready to do a gdk_seat_grab. Another part is that - completely mysteriously as far as I can see - a _failed_ gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of calling gdk_window_hide on the window you gave it! So I've done a considerable restructuring that means we no longer attempt to do the keyboard grab synchronously in gtk_askpass_setup. Instead, we make keyboard grab attempts during the run of gtk_main, scheduling each one on a timer if the previous attempt fails. This means I need a visual indication of 'not ready for you to type anything yet', which I've arranged by filling in the three drawing areas to mid-grey. At the point when the keyboard grab completes and the window becomes receptive to input, they turn into the usual one black and two white.
2018-05-13 21:56:52 +00:00
return ctx->error_message;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
}
}
#ifdef TEST_ASKPASS
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
void modalfatalbox(const char *p, ...)
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
{
va_list ap;
fprintf(stderr, "FATAL ERROR: ");
va_start(ap, p);
vfprintf(stderr, p, ap);
va_end(ap);
fputc('\n', stderr);
exit(1);
}
int main(int argc, char **argv)
{
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool success;
int exitcode;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
char *ret;
Arm: turn on PSTATE.DIT if available and needed. DIT, for 'Data-Independent Timing', is a bit you can set in the processor state on sufficiently new Arm CPUs, which promises that a long list of instructions will deliberately avoid varying their timing based on the input register values. Just what you want for keeping your constant-time crypto primitives constant-time. As far as I'm aware, no CPU has _yet_ implemented any data-dependent optimisations, so DIT is a safety precaution against them doing so in future. It would be embarrassing to be caught without it if a future CPU does do that, so we now turn on DIT in the PuTTY process state. I've put a call to the new enable_dit() function at the start of every main() and WinMain() belonging to a program that might do cryptography (even testcrypt, in case someone uses it for something!), and in case I missed one there, also added a second call at the first moment that any cryptography-using part of the code looks as if it might become active: when an instance of the SSH protocol object is configured, when the system PRNG is initialised, and when selecting any cryptographic authentication protocol in an HTTP or SOCKS proxy connection. With any luck those precautions between them should ensure it's on whenever we need it. Arm's own recommendation is that you should carefully choose the granularity at which you enable and disable DIT: there's a potential time cost to turning it on and off (I'm not sure what, but plausibly something of the order of a pipeline flush), so it's a performance hit to do it _inside_ each individual crypto function, but if CPUs start supporting significant data-dependent optimisation in future, then it will also become a noticeable performance hit to just leave it on across the whole process. So you'd like to do it somewhere in the middle: for example, you might turn on DIT once around the whole process of verifying and decrypting an SSH packet, instead of once for decryption and once for MAC. With all respect to that recommendation as a strategy for maximum performance, I'm not following it here. I turn on DIT at the start of the PuTTY process, and then leave it on. Rationale: 1. PuTTY is not otherwise a performance-critical application: it's not likely to max out your CPU for any purpose _other_ than cryptography. The most CPU-intensive non-cryptographic thing I can imagine a PuTTY process doing is the complicated computation of font rendering in the terminal, and that will normally be cached (you don't recompute each glyph from its outline and hints for every time you display it). 2. I think a bigger risk lies in accidental side channels from having DIT turned off when it should have been on. I can imagine lots of causes for that. Missing a crypto operation in some unswept corner of the code; confusing control flow (like my coroutine macros) jumping with DIT clear into the middle of a region of code that expected DIT to have been set at the beginning; having a reference counter of DIT requests and getting it out of sync. In a more sophisticated programming language, it might be possible to avoid the risk in #2 by cleverness with the type system. For example, in Rust, you could have a zero-sized type that acts as a proof token for DIT being enabled (it would be constructed by a function that also sets DIT, have a Drop implementation that clears DIT, and be !Send so you couldn't use it in a thread other than the one where DIT was set), and then you could require all the actual crypto functions to take a DitToken as an extra parameter, at zero runtime cost. Then "oops I forgot to set DIT around this piece of crypto" would become a compile error. Even so, you'd have to take some care with coroutine-structured code (what happens if a Rust async function yields while holding a DIT token?) and with nesting (if you have two DIT tokens, you don't want dropping the inner one to clear DIT while the outer one is still there to wrongly convince callees that it's set). Maybe in Rust you could get this all to work reliably. But not in C! DIT is an optional feature of the Arm architecture, so we must first test to see if it's supported. This is done the same way as we already do for the various Arm crypto accelerators: on ELF-based systems, check the appropriate bit in the 'hwcap' words in the ELF aux vector; on Mac, look for an appropriate sysctl flag. On Windows I don't know of a way to query the DIT feature, _or_ of a way to write the necessary enabling instruction in an MSVC-compatible way. I've _heard_ that it might not be necessary, because Windows might just turn on DIT unconditionally and leave it on, in an even more extreme version of my own strategy. I don't have a source for that - I heard it by word of mouth - but I _hope_ it's true, because that would suit me very well! Certainly I can't write code to enable DIT without knowing (a) how to do it, (b) how to know if it's safe. Nonetheless, I've put the enable_dit() call in all the right places in the Windows main programs as well as the Unix and cross-platform code, so that if I later find out that I _can_ put in an explicit enable of DIT in some way, I'll only have to arrange to set HAVE_ARM_DIT and compile the enable_dit() function appropriately.
2024-12-19 08:47:08 +00:00
enable_dit(); /* maybe overkill, but we _are_ handling a secret */
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
gtk_init(&argc, &argv);
if (argc != 2) {
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
success = false;
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
ret = dupprintf("usage: %s <prompt text>", argv[0]);
} else {
Bring the gtkask.c test main() up to date. I changed the prototype of gtk_askpass_main() since I last tried to compile that standalone test program.
2015-09-26 09:53:32 +00:00
ret = gtk_askpass_main(NULL, "Enter passphrase", argv[1], &success);
Unix Pageant: implement GUI passphrase prompting. I've written my own analogue of OpenSSH's ssh-askpass. At the moment, it's contained inside Pageant proper, though it could easily be compiled into a standalone binary as well or instead. Unlike OpenSSH's version, I don't use a GTK edit box; instead I just process key events myself and append them to a buffer. The big advantage of doing this is that I can arrange for ^W and ^U to function as they do in terminal line editing, i.e. delete a word or delete the whole line. ^W in particular is really valuable when typing a multiple-word passphrase unseen. If you feel yourself making the kind of typo in which you're not sure if you pressed six keys or just five, you can hit ^W and restart just that word, without either having to go right back to the beginning or carry on and see if you feel lucky. A delete-word function would of course be an information leak in even an obscured edit box (displaying a blob per character), so instead I give a visual acknowledgment of keypresses by a more ad-hoc means: I display three lights in the box, and every meaningful keypress turns off the currently active one and instead turns on a randomly selected one of the others. (So the lit light doesn't even indicate _mod 3_ how many keys have been pressed.)
2015-05-13 12:55:08 +00:00
}
if (!success) {
fputs(ret, stderr);
fputc('\n', stderr);
exitcode = 1;
} else {
fputs(ret, stdout);
fputc('\n', stdout);
exitcode = 0;
}
smemclr(ret, strlen(ret));
return exitcode;
}
#endif
Reference in New Issue Copy Permalink