Mirrors | Updates | Feedback | Changes | Wishlist | Team
Currently, when PuTTY makes a request to Pageant, it waits in a tight loop for the answer. Really it should be able to answer Windows messages and do other housekeeping tasks while it's waiting for the answer. This would enable Pageant to do a variety of time-consuming things in the course of answering a request.
SGT, 2003-04-28: This was indeed tricky, but should now be done.
Update, 2004-01-24: Bah! Nicolas Barry correctly points out that my async agent code simply doesn't work - if multiple concurrent agent requests are attempted, some of them will fail for no apparent reason. I assume concurrent SendMessage() calls don't work in the Windows API, or some such. So I'm commenting out the async code for the moment (there wasn't a Windows Pageant that made helpful use of it anyway yet) and returning to the drawing board.
Update, 2004-03-22: Since I've just written a long mail to one user explaining why this is a difficult problem, it seems sensible to paste it in here too.
Currently, PuTTY communicates with Pageant by means of sending a Windows message asking for an authentication, and waiting for Pageant's Windows message handler to return success or failure. This is fine as long as Pageant can process every request in negligible time. However, as soon as Pageant starts needing to do anything GUI-related in response to a request (such as putting up a request to ask the user for a passphrase), things get tricky. If Pageant puts up a dialog box, this causes a subsidiary message loop to be run (so that it can receive messages on the dialog box itself), and at the end of that loop it can reply to the original message; the difficulty is what to do if a second PuTTY sends _another_ signature request message which requires another dialog box while the first dialog box is up. Pageant cannot sensibly choose in what order to reply to the messages; it can't accept the new message because then it would have to stop processing any messages on the first dialog; it can't delay accepting the new message because you can't do that with SendMessage events (believe me, I've tried). It has no feasible option except to completely freeze the first dialog and put up a second, which just isn't acceptable (particularly if the two requests were for the _same_ key, in which case obviously what it really wants to do is finish asking for the passphrase the first time and then reply to both requests).
So a wholly new mechanism is required. Options include:
Audit trail for this wish.