PuTTY wish pageant-without-gtk

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Privacy | Changes | Wishlist

summary: Unix Pageant should be able to build without GTK
class: wish: This is a request for an enhancement.
difficulty: fun: Just needs tuits, and not many of them.
priority: low: We aren't sure whether to fix this or not.
fixed-in: d6a83fe336230d60dcb166b9f9ffabe451404c5a (0.78)

Currently, Unix Pageant insists on linking against GTK, so that if you run it in the context of a GUI login session, it can use GTK to put up passphrase prompts. (Either when acting as a client and adding a key, or when acting as a server and decrypting a key that was added in still-encrypted form.)

There are plenty of things Unix Pageant can still usefully do without needing to talk to GTK. So it should still be possible to compile a reduced-functionality version of it when GTK is not detected at configure time.

Now that PuTTY's build system is based on cmake, this wouldn't be especially difficult. (In the old mkfiles.pl system it would probably have been more painful.)

For the case where Pageant is running in client mode, the no-GTK behaviour would be: if you need to display a passphrase prompt, you have no available options for that except the GTK prompt (i.e., there's no controlling terminal), and you don't have GTK, then fail.

When Pageant is in server mode, we could do the same thing, but that would be a bit unfortunate, because the effect would be that a user could add their encrypted key as normal, and then find they had no way at all to decrypt it. A better approach would be to reject the attempt to add the encrypted key, if Pageant realises that it would have no available way to present a passphrase prompt to decrypt it. [Our initial implementation ended up with the unhelpful behaviour.]


If you want to comment on this web site, see the Feedback page.
Audit trail for this wish.
(last revision of this bug record was at 2022-10-28 17:52:56 +0100)