PuTTY wish pageant-named-pipe

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 | Changes | Wishlist

summary: Replace Windows Pageant's IPC with named pipes
class: wish: This is a request for an enhancement.
difficulty: tricky: Needs many tuits.
blocks: pageant-deferred-decrypt pageant-forwarding-path pageant-key-confirm
priority: medium: This should be fixed one day.
fixed-in: 98538caa39d20f3efe8de307fa5169e9fb0787d2 2020-01-26 (0.75)

Windows Pageant's method of communicating with clients, using WM_COPYDATA and a piece of shared memory, is absolutely horrible. It dates from early in Win32's history, before more sensible IPC systems were widespread.

It would be good to begin the process of replacing it with a sensible mechanism based on Windows named pipes, the same IPC mechanism that connection-sharing instances of PuTTY use to talk to each other.

Apart from the purely aesthetic 'not being disgusting' sorts of advantages, this IPC system would be an improvement on the current Pageant one in several ways:

Of course, we would have to continue supporting the old WM_COPYDATA system in parallel for (at least) a long time, because an unknown number of third-party clients use it. So any new features that depend on the new IPC (as discussed above) would have to be implemented in such a way that WM_COPYDATA clients would cope somehow.

Actually setting up the named pipe system itself should be reasonably easy these days: named pipe IPC is fully implemented (including the right security setup) for connection sharing, and the Pageant code has already been restructured to involve a Plug data structure suitable for passing straight to new_named_pipe_listener() (though of course we'd also have to endow Windows Pageant with the same kind of main event loop PuTTY has). The client side shouldn't be any harder.

The more interesting question would be how to support both IPC systems in one program, in the most helpful possible way. One thought I've been considering runs along the following lines:

Doing it this way might well manage to get round some of the limitations of the Windows-message IPC system: in particular, it might still be possible to provide deferred key decryption to WM_COPYDATA clients, because the Windows message activity required to present the passphrase prompt would all happen in one thread, while the other thread was still blocked waiting to reply to the WM_COPYDATA.

But if that turns out not to work (e.g. perhaps there's a time limit on how long you can delay responding to a SendMessage, or perhaps I've misunderstood how multiple threads' message queues interact), then the fallback position would be to simply not present any key to WM_COPYDATA clients that isn't immediately usable without user interaction.


2020-01: implemented, including moving WM_COPYDATA servicing into a subthread.


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 2021-04-08 01:12:28 +0100)