This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: getpass incorrectly displays password prompt on stderr on fallback
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.5
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Matt Hooks, ethan.furman, martin.panter, r.david.murray, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2016-02-12 21:10 by Matt Hooks, last changed 2022-04-11 14:58 by admin. This issue is now closed.

File name Uploaded Description Edit
26352_avoid_prompt_on_stderr.patch Matt Hooks, 2016-02-12 21:46 review
Messages (4)
msg260202 - (view) Author: Matt Hooks (Matt Hooks) Date: 2016-02-12 21:10
When calling getpass.getpass(), certain circumstances cause it to fallback to getpass.fallback_getpass, such as when swapping out sys.stdin for another object in a unit test.

In such a circumstance, fallback_getpass may be called with stream=None when getpass itself was called without a stream.  fallback_getpass needs a stream to write the "Warning: Password input may be echoed" warning to, and reasonably chooses stderr.  However, this choice persists down into getpass._raw_input, where the user is then shown the password prompt on stderr as well.  Instead of on stderr, the user should get the password prompt on stdout.

tl;dr: Some calls to getpass.getpass result in a password prompt on stderr.

Bad behavior: password prompt displayed over stderr.
Expected behavior: password prompt should be on stdout.

Found in 3.4, looks like it's the same in 3.5.

I will attach a patch in a few moments, after I get my dev environment sorted out.
msg260204 - (view) Author: Matt Hooks (Matt Hooks) Date: 2016-02-12 21:46
Patch attached.

I'm unsure whether forcing the warning message to stderr is the right choice here, but it seems unlikely that users would want their warning and password prompt on the same stream.  The alternative here would be a second kwarg, but that seems overkill.
msg265055 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-05-07 09:40
Why do you think using stderr is bad behaviour, or that a user would want the prompt and warning on different streams? As far as I can tell, the documentation already says that stderr is used by default, and there are other unpatched references to sys.stderr left.

See also Issue 1927, where Serhiy wants to change input() to always prompt to stderr rather than stdout.
msg265065 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-05-07 12:57
stdout is much more likely to be redirected than stderr, so falling back to stderr makes more sense than falling back to stdout.  In the normal case, the prompt is shown regardless of whether stdout is redirected, and we're trying our best to replicate that in the fallback.
Date User Action Args
2022-04-11 14:58:27adminsetgithub: 70540
2016-05-07 12:57:34r.david.murraysetstatus: pending -> closed

nosy: + r.david.murray
messages: + msg265065

resolution: rejected
stage: patch review -> resolved
2016-05-07 10:37:27serhiy.storchakasetstatus: open -> pending
nosy: + serhiy.storchaka
2016-05-07 09:40:46martin.pantersetnosy: + martin.panter

messages: + msg265055
stage: patch review
2016-02-12 21:46:53Matt Hookssetfiles: + 26352_avoid_prompt_on_stderr.patch
keywords: + patch
messages: + msg260204
2016-02-12 21:38:01ethan.furmansetnosy: + ethan.furman
2016-02-12 21:10:50Matt Hookscreate