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

601 строка
18 KiB
C
Исходник Обычный вид История

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 15:55:08 +03: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 17:04:28 +03: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 15:55:08 +03: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 17:06:15 +03: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 15:55:08 +03: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 17:06:15 +03: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 15:55:08 +03: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 23:05:56 +03:00
#include "gtkfont.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 17:04:28 +03: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 17:45:18 +03: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 17:04:28 +03: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 15:55:08 +03: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 23:05:56 +03: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 15:55:08 +03: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 23:05:56 +03: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-14 00:56:52 +03: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 15:55:08 +03: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 17:04:28 +03: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 15:55:08 +03: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 17:04:28 +03: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 23:05:56 +03: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 15:55:08 +03: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-14 00:56:52 +03: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 23:05:56 +03: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-14 00:56:52 +03:00
char *error_message; /* if we finish without a passphrase */
char *passphrase; /* if we finish with one */
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 15:55:08 +03:00
int passlen, passsize;
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 13:21:54 +03: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 16:36:32 +03: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-14 00:56:52 +03: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 15:55:08 +03:00
};
static void visually_acknowledge_keypress(struct askpass_ctx *ctx)
{
int new_active;
new_active = rand() % (N_DRAWING_AREAS - 1);
if (new_active >= ctx->active_area)
new_active++;
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-14 00:56:52 +03: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 15:55:08 +03: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-14 00:56:52 +03: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 15:55:08 +03:00
gtk_widget_queue_draw(ctx->drawingareas[new_active].area);
ctx->active_area = new_active;
}
static int last_char_len(struct askpass_ctx *ctx)
{
/*
* GTK always encodes in UTF-8, so we can do this in a fixed way.
*/
int i;
assert(ctx->passlen > 0);
i = ctx->passlen - 1;
while ((unsigned)((unsigned char)ctx->passphrase[i] - 0x80) < 0x40) {
if (i == 0)
break;
i--;
}
return ctx->passlen - i;
}
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 17:04:28 +03:00
static void add_text_to_passphrase(struct askpass_ctx *ctx, gchar *str)
{
int len = strlen(str);
if (ctx->passlen + len >= ctx->passsize) {
/* Take some care with buffer expansion, because there are
* pieces of passphrase in the old buffer so we should ensure
* realloc doesn't leave a copy lying around in the address
* space. */
int oldsize = ctx->passsize;
char *newbuf;
ctx->passsize = (ctx->passlen + len) * 5 / 4 + 1024;
newbuf = snewn(ctx->passsize, char);
memcpy(newbuf, ctx->passphrase, oldsize);
smemclr(ctx->passphrase, oldsize);
sfree(ctx->passphrase);
ctx->passphrase = newbuf;
}
strcpy(ctx->passphrase + ctx->passlen, str);
ctx->passlen += len;
visually_acknowledge_keypress(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 15:55:08 +03: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 17:04:28 +03: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 18:23:54 +03: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 15:55:08 +03: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 18:23:54 +03:00
} else if (event->keyval == GDK_KEY_Escape &&
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 15:55:08 +03:00
smemclr(ctx->passphrase, ctx->passsize);
ctx->passphrase = 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-14 00:56:52 +03:00
ctx->error_message = dupstr("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 15:55:08 +03:00
gtk_main_quit();
} 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 17:04:28 +03: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 15:55:08 +03:00
if (gtk_im_context_filter_keypress(ctx->imc, event))
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 17:04:28 +03: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 15:55:08 +03:00
if (event->type == GDK_KEY_PRESS) {
if (!strcmp(event->string, "\x15")) {
/* Ctrl-U. Wipe out the whole line */
ctx->passlen = 0;
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. */
while (ctx->passlen > 0) {
char deleted, prior;
ctx->passlen -= last_char_len(ctx);
deleted = ctx->passphrase[ctx->passlen];
prior = (ctx->passlen == 0 ? ' ' :
ctx->passphrase[ctx->passlen-1]);
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 18:23:54 +03: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 15:55:08 +03:00
/* Backspace. Delete one character. */
if (ctx->passlen > 0)
ctx->passlen -= last_char_len(ctx);
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 17:04:28 +03: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 15:55:08 +03: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 17:04:28 +03: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 15:55:08 +03: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 17:04:28 +03: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 15:55:08 +03: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 17:04:28 +03: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 15:55:08 +03: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);
return TRUE;
}
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 23:05:56 +03: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-14 00:56:52 +03: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 23:05:56 +03: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-14 00:56:52 +03:00
gdk_gc_set_foreground(gc, &ctx->cols[ctx->state]);
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 23:05:56 +03:00
gdk_draw_rectangle(win, gc, TRUE, 0, 0, ctx->width, ctx->height);
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 16:34:19 +03: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);
return TRUE;
}
#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 15:55:08 +03: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 23:05:56 +03: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
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 15:55:08 +03: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 16:34:19 +03: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 15:55:08 +03: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-14 00:56:52 +03: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 15:55:08 +03: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-14 00:56:52 +03: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 16:36:32 +03: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 13:21:54 +03: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 16:36:32 +03: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 13:21:54 +03: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-14 00:56:52 +03: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 13:21:54 +03:00
seat = gdk_display_get_default_seat
(gtk_widget_get_display(ctx->dialog));
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-14 00:56:52 +03: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 13:21:54 +03: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-14 00:56:52 +03:00
ret = gdk_seat_grab(seat, gdkw, GDK_SEAT_CAPABILITY_KEYBOARD,
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 13:21:54 +03: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-14 00:56:52 +03: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 13:21:54 +03: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 16:36:32 +03:00
*/
GdkDeviceManager *dm;
GdkDevice *pointer, *keyboard;
dm = gdk_display_get_device_manager
(gtk_widget_get_display(ctx->dialog));
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-14 00:56:52 +03: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 16:36:32 +03: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-14 00:56:52 +03: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 16:36:32 +03: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-14 00:56:52 +03: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 16:36:32 +03: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-14 00:56:52 +03: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 16:36:32 +03:00
ctx->keyboard = keyboard;
ret = gdk_device_grab(ctx->keyboard,
gtk_widget_get_window(ctx->dialog),
GDK_OWNERSHIP_NONE,
TRUE,
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),
FALSE, GDK_CURRENT_TIME);
#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-14 00:56:52 +03: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 16:36:32 +03: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-14 00:56:52 +03: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 15:55:08 +03: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-14 00:56:52 +03: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 15:55:08 +03: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-14 00:56:52 +03:00
ctx->active_area = rand() % N_DRAWING_AREAS;
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 15:55:08 +03: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-14 00:56:52 +03:00
return FALSE;
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) {
smemclr(ctx->passphrase, ctx->passsize);
ctx->passphrase = NULL;
ctx->error_message = dupstr("unable to grab keyboard after 5 seconds");
gtk_main_quit();
} 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 15:55:08 +03: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-14 00:56:52 +03: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 15:55:08 +03: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 17:45:18 +03: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 15:55:08 +03:00
ctx->passlen = 0;
ctx->passsize = 2048;
ctx->passphrase = snewn(ctx->passsize, char);
/*
* 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 17:45:18 +03: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 15:55:08 +03: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 17:45:18 +03:00
gtk_window_set_position(GTK_WINDOW(ctx->dialog), GTK_WIN_POS_CENTER);
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 15:55:08 +03: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 17:45:27 +03: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 13:09:20 +03:00
gtk_widget_show(ctx->promptlabel);
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 15:55:08 +03: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 17:45:27 +03:00
#if GTK_CHECK_VERSION(3,0,0)
gtk_label_set_width_chars(GTK_LABEL(ctx->promptlabel), 48);
#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 17:45:18 +03:00
our_dialog_add_to_content_area(GTK_WINDOW(ctx->dialog),
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 17:04:28 +03: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 15:55:08 +03: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 17:04:28 +03: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 23:05:56 +03: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-14 00:56:52 +03: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 23:05:56 +03:00
gdk_colormap_alloc_colors(ctx->colmap, ctx->cols, 2,
FALSE, TRUE, success);
if (!success[0] | !success[1])
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 17:45:18 +03: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 15:55:08 +03: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 23:05:56 +03: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 15:55:08 +03: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 23:05:56 +03: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-14 00:56:52 +03: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 15:55:08 +03: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 17:45:18 +03:00
gtk_box_pack_end(action_area, ctx->drawingareas[i].area,
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 19:29:02 +03: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 16:34:19 +03: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 19:29:02 +03: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 16:34:19 +03: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 13:49:05 +03: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 15:55:08 +03: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-14 00:56:52 +03: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 15:55:08 +03: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.
*/
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-14 00:56:52 +03: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 17:04:28 +03: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 15:55:08 +03: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 17:04:28 +03: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 15:55:08 +03: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-14 00:56:52 +03: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 15:55:08 +03: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-14 00:56:52 +03: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 15:55:08 +03: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-14 00:56:52 +03: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 15:55:08 +03: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-14 00:56:52 +03: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 15:55:08 +03: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 13:21:54 +03: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-14 00:56:52 +03: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 13:21:54 +03: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-14 00:56:52 +03: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 16:36:32 +03: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 15:55:08 +03: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 16:36:32 +03: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 15:55:08 +03:00
gtk_grab_remove(ctx->promptlabel);
if (ctx->passphrase) {
assert(ctx->passlen < ctx->passsize);
ctx->passphrase[ctx->passlen] = '\0';
}
gtk_widget_destroy(ctx->dialog);
}
static int setup_gtk(const char *display)
{
static int gtk_initialised = FALSE;
int argc;
char *real_argv[3];
char **argv = real_argv;
int ret;
if (gtk_initialised)
return TRUE;
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;
}
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-23 01:10:05 +03:00
const int buildinfo_gtk_relevant = 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 15:55:08 +03:00
char *gtk_askpass_main(const char *display, const char *wintitle,
const char *prompt, int *success)
{
struct askpass_ctx actx, *ctx = &actx;
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-14 00:56:52 +03: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 15:55:08 +03:00
/* In case gtk_init hasn't been called yet by the program */
if (!setup_gtk(display)) {
*success = FALSE;
return dupstr("unable to initialise GTK");
}
if ((err = gtk_askpass_setup(ctx, wintitle, prompt)) != NULL) {
*success = FALSE;
return dupprintf("%s", err);
}
gtk_main();
gtk_askpass_cleanup(ctx);
if (ctx->passphrase) {
*success = TRUE;
return ctx->passphrase;
} else {
*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-14 00:56:52 +03: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 15:55:08 +03: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 13:15:42 +03: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 15:55:08 +03: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)
{
int success, exitcode;
char *ret;
gtk_init(&argc, &argv);
if (argc != 2) {
success = FALSE;
ret = dupprintf("usage: %s <prompt text>", argv[0]);
} else {
srand(time(NULL));
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 12:53:32 +03: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 15:55:08 +03: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