Hello, Éric and Gregory, this patch also addresses the problem 
that 'one newline too much' may be written in case of errors. 
The problem is already present in the unpatched code, 
and i admit that 11466.3.patch doesn't fix it.

All of this is written under the assumption that i may touch only 
unix_getpass(), not the rest of this file; it would be easier if 
_raw_input() would take a terminal_setup=False argument and 
encapsulate echoing of a final newline ...

About security: i think that you, Éric, have referred to this 
when you've said "your patch is not uncontroversial". 
There is http://mail.python.org/pipermail/python-dev/2003-December/040579.html, 
and, after looking into OpenBSD:lib/libc/gen/readpassphrase.c, 
i must admit that it would possibly be much better to use a native 
getpass(3) implementation if one is available.

(OpenBSD's getpass() *does not* set ISIG, it just takes care about 
signals and re-kill(2)s them as necessary; it restarts the entire 
getpass() cycle if it's TSTP/TTIN/TTOU and re-kill(2) returns.  
But this belongs to #11236, i guess.)

The mail on #dev is more than seven years old, however, and still 
this getpass.getpass() uses it's naive (compared to OpenBSD, say) 
approach.  And that does not get worse with my patch in the end.

I also want to note that getpass.getpass() may throw IOError 
undocumented, with and without 11466.4.patch applied; 
it does so cleanly upon a49bda5ff3d5. 
And finally i am thankful for all the feedback i can get.