I am comparing getpass.py (http://cvs.osafoundation.org/index.cgi/osaf/chandler/python/Lib/getpass.py) and getpass.c from glibc (http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/misc/getpass.c?rev=1.18&content-type=text/x-cvsweb-markup&cvsroot=glibc). Here are the differences that I identified, some of which may or may not be bugs in getpass.py: 1. getpass.c sets ~ISIG in addition to ~ECHO. 2. getpass.c locks "stdin". 3. getpass.c makes sure the "stdin" is closed even if the thread is cancelled. 4. getpass.c explicitly flushes "stdin" after outputting the promt and before reading the password. 5. getpass.c opens "stdin" in "c" mode. This sets _IO_FLAGS2_NOTCANCEL, whatever that means. Maybe it has something to do with thread cancellation, maybe not. (http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/libio/fileops.c?rev=1.101&content-type=text/x-cvsweb-markup&cvsroot=glibc) 1,2,3,5 are possible security holes in addition to being possible bugs. Although I don't completely understand all the details, it appears to me that getpass.c is more correct then getpass.py. Suggestion/RFC: either implement the same functionality or a portion thereof in getpass.py, or implement it using getpass(3) directly, at least when linking with glibc. More references: http://www.python.org/doc/current/lib/module-getpass.html http://www.opengroup.org/onlinepubs/007908799/xsh/getpass.html 'info getpass' It would help if we knew whether login, passwd, chfn, su, sudo, yppasswd, etc, use getpass(3) or not. If yes, the answer would be a no-brainer to me. Oleg.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4