ipython
Ipykernel replacement of `getpass` not fully compatible with it
The getpass API requires that the GetPassWarning is generated in case a password cannot be asked to the user in a secure way.
This is an important piece of the API, because it lets the programmer turn the warning into an error to handle the case when the terminal is not suited to securely prompt for a password before the user is asked for a password. In turn this is important because most users will carelessly type in a password regardless of any warning and is particularly bad for interfaces where the password will remain available for view via scrollback. Being able to handle the condition will let the program try different ways to get the password rather than prompting the user in an insecure way.
The problem here is that ipykernel replaces getpass with its own version that does not issue the GetPassWarning, so resulting in a different API from the standard getpass that ends up with the code prompting the user for a password insecurely without even realizing it.
At present time the workaround is clearly for the code to check if getpass comes from ipykernel and deal with this case specially.
Hm, I suppose we'd need to figure out some way for frontends to indicate that they don't support password inputs. We could say that the message spec requires that password inputs be safely input. Of Jupyter frontends, I think QtConsole is the only one I'm aware of that doesn't support proper password input. I don't know if that's fixable or not.
Would not be able to say if it is easier to fix the QtConsole so that it can hide the user input or to provide a general mechanism so that the frontends can report to the backend the need to issue the GetPassWarning so that the asking of a password can be aborted if needed. The second might be an investment if QtConsole is not fixable, or is not the only frontend with the issue or if further frontends are conceived in the future that might not support hidden user input.
The getpass API requires that the GetPassWarning is generated in case a password cannot be asked to the user in a secure way.
Just to be clear, the warning is not about being asked in a secure way, it is only about whether the password will be echoed or not:
A UserWarning subclass issued when password input may be echoed.
I want to make that distinction, since the password will be transmitted in a plain text message back to the kernel, and it would be hard for us to verify that the entire exchange is secure.
However, it should be easier for frontends to indicate whether they will echo the password.
We already have a way for frontends to indicate if they support the input channel. Perhaps that could be extended to also give this information about passwords? Or I like Min's suggestion of just requiring that the frontend not echo the password.
