PuTTY wish pageant-named-pipe

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

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:

• Independent of Windows messages: Pageant would no longer be constrained by the structure of the Windows message loop to respond to agent requests before it can resume GUI activity. This opens the way to implement features such as pageant-deferred-decrypt.
• Unbounded: there would no longer be a need to impose a strict upper limit on the length of a Pageant request or response. (The current implementation has an arbitrary limit of 8kbyte, and so breaks ungracefully when you have a large number of keys in Pageant.)
• Stateful: it permits Pageant to know which sequences of requests it receives are part of the same connection from the same client, which unblocks blue-sky possibilities such as pageant-forwarding-path.

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:

• Divide Windows Pageant into two threads.
• The main thread runs both the visible GUI and the named-pipe listener, and has a main event loop that selects between its Windows message queue and a set of event objects from winhandl.c, more or less exactly like PuTTY's event loop.
• The secondary thread creates the invisible window that WM_COPYDATA clients will send their request messages to. This should (if I've correctly understood how message queues, windows and threads interact) cause the secondary thread to receive those agent requests, and the main thread to receive all other GUI activity.
• The secondary thread handles each WM_COPYDATA request by opening a connection to the named pipe, just as if it was a client in a separate process. It waits for the response before replying to the message.

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.