why are you letting jwz do your thinking for you?
An alternative, related question, why are you saying things without references?
I don't have a good knowledge of the intricacies of screen locking and controlling input devices, so I have to refer to others who I consider to share my general view point, but who appear to be more knowledgeable in a particular area. This is a very common approach in research, and separates out the people who have their own theories based purely on anecdotal evidence from the people who build on the theories and evidence of other research.
My observation is that almost every program has bugs, and the number of bugs increase (in a non-linear fashion) with the size of a project. Bugs in software that deals with authentication are particularly serious, because a bug may be exploitable to give someone privileges that they would otherwise not have (see toolkit discussion).
If you disagree, please address why security is something that should be handled by screensavers, instead of the display manager.
I don't feel that I need to do this, because it has already been addressed in the toolkit discussion. You're giving off the impression that you haven't actually read the toolkit discussion. Please provide some other evidence why the arguments put forward by JWZ are incorrect (preferably something other than "he is a pretentious idiot, so he's wrong"). Anyway, because you're giving this impression, I feel it necessary to post more of that discussion here:
So, you want xscreensaver to invoke the "unlock dialog" program and wait for a response. The unlocker would use a GUI toolkit, and would be linked against the various security libraries. Perhaps the way it would work is that it would print either "yes" or "no" on stdout, depending on whether a password was correctly entered. Were it to crash, the daemon would take that that to mean "no"...
In fact, this approach would actually reduce the number of libraries (and thus, lines of code) in the daemon itself, since the daemon would not need to link against things like PAM and crypto. That's a good thing.
So that doesn't sound hard so far, except that the xscreensaver daemon has the keyboard grabbed. It's pretty important that it hold that grab, because otherwise keystrokes tend to go "through" the xscreensaver window and reach random desktop windows underneath.
This [raises] the question of, how do the keystrokes get to the unlock dialog at all? That's a difficult question. Understanding how to do that right requires a lot of knowledge about X (which I have) but also probably a lot of knowledge about foreign-language input methods and screen readers and other accessibility-ware (which I do not have.) ...
In the current system, where the same process is the creator of both the screen-blanking window and the unlock dialog, this is not a problem: that process gets all the events it wants. But when they are in different processes, we need a way for the keyboard and mouse events to get to the process driving the unlock dialog. So you'd like to transfer the grabs from the xscreensaver daemon to the unlock dialog, and then transfer them back afterward. Unfortunately, there is no way to transfer grabs atomically in X. ...
Another possibility is for the xscreensaver daemon to keep its grabs, meaning that all keyboard and mouse events would go to it; but then for it to use XSendEvent() to generate synthetic events on the lock dialog window. That is, the xscreensaver daemon would read a KeyPress, and then would simulate an exact duplicate of that KeyPress on the lock dialog window.
[arguments against this: Applications can tell the difference between real and synthetic events, so might reject synthetic events as a security measure. Input methods need to be embedded in the dialog, rather than as a separate window] ...
Making the xscreensaver unlock dialog securely use a toolkit is difficult, but possible, were a knowledgeable person to do the work. If the work were done well (by which I mean: clearly commented and documented, and with obvious attention paid to the security implications) I would be happy to incorporate those changes into the xscreensaver distribution.
Making the unlock dialog also be able to take advantage of accessibility tools is probably a lot harder. I don't know how much harder, because I'm not an accessibility expert. But anyone intending to implement that had better be both an expert on accessibility, and well versed in secure X11 programming, because the security implications of getting it wrong would be dire indeed.