Re: [Python-ideas] [Python-Dev] Proposal for the getpass module
[redirecting to python-ideas] On Sat, Feb 6, 2010 at 4:08 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
Hello,
I would like to propose a small change in the getpass module so it's able to get passwords from keyrings (like KWallet, Keychain, etc)
The idea is to provide a getpass.cfg configuration file where people can provide the name of a function to use when getpass is called. Then third-party projects can implement this function. For example the Python Keyring library.[1] could be installed and configured to be used by people that wants getpass calls to be handled by this tool.
That's a backward compatible change, and it avoids adding any new module in the stdlib. Plus, it offers a greatly improved getpass module with no risks for the stdlib stability : it becomes a reference implementation with an interface for third-party implementers.
A prototype is here : http://bitbucket.org/tarek/getpass/ (work in progress but you can get the idea)
Don't you usually have to tell the keyring which password to retrieve? The signature for getpass() doesn't have enough info for that. I'm not sure that not adding a new module to the stdlib is a sufficient reason to foist the new semantics on an old function. -- --Guido van Rossum (python.org/~guido)
On Sun, Feb 7, 2010 at 1:30 AM, Guido van Rossum <guido@python.org> wrote:
[redirecting to python-ideas] [..]
Don't you usually have to tell the keyring which password to retrieve? The signature for getpass() doesn't have enough info for that.
I've slightly changed the signature to add two new options: - service : the name of the service the password is associated to (defaults to 'Python') - username: the name of the user (defaults to the value returned by getpass.getuser() ) These options are not used by the existing functions, but make it possible for a keyring API to handle the request properly by getting the password stored for service+username
I'm not sure that not adding a new module to the stdlib is a sufficient reason to foist the new semantics on an old function.
I've done it this way so the "Distutils calls getpass" use case would work transparently, but maybe it's a bad idea to add a hook like that after all. Maybe a new API for this would be better, with a dummy implementation in the stdlib and a way to configure an external tool to be used. Tarek -- Tarek Ziadé | http://ziade.org
On Sat, Feb 6, 2010 at 4:42 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
On Sun, Feb 7, 2010 at 1:30 AM, Guido van Rossum <guido@python.org> wrote:
[redirecting to python-ideas] [..]
Don't you usually have to tell the keyring which password to retrieve? The signature for getpass() doesn't have enough info for that.
I've slightly changed the signature to add two new options:
- service : the name of the service the password is associated to (defaults to 'Python') - username: the name of the user (defaults to the value returned by getpass.getuser() )
These options are not used by the existing functions, but make it possible for a keyring API to handle the request properly by getting the password stored for service+username
You really need to think of this as adding a new API whose default behavior is to call the original getpass() function. I don't see any advantage to giving this function the same name as the classic getpass() -- the default of getting a password named "Python" is unlikely to be useful. (If you disagree, please provide a real use case.)
I'm not sure that not adding a new module to the stdlib is a sufficient reason to foist the new semantics on an old function.
I've done it this way so the "Distutils calls getpass" use case would work transparently, but maybe it's a bad idea to add a hook like that after all. Maybe a new API for this would be better, with a dummy implementation in the stdlib and a way to configure an external tool to be used.
What's this use case? What password does distutils need to ask for? Maybe the new API should just be a utility in distutils? -- --Guido van Rossum (python.org/~guido)
On Sun, Feb 7, 2010 at 2:27 AM, Guido van Rossum <guido@python.org> wrote: [..]
You really need to think of this as adding a new API whose default behavior is to call the original getpass() function. I don't see any advantage to giving this function the same name as the classic getpass() -- the default of getting a password named "Python" is unlikely to be useful.
(If you disagree, please provide a real use case.)
I agree. Make sense now
I'm not sure that not adding a new module to the stdlib is a sufficient reason to foist the new semantics on an old function.
I've done it this way so the "Distutils calls getpass" use case would work transparently, but maybe it's a bad idea to add a hook like that after all. Maybe a new API for this would be better, with a dummy implementation in the stdlib and a way to configure an external tool to be used.
What's this use case? What password does distutils need to ask for?
When you register or upload a package to PyPI, you have two choices. Either you store your password in clear text in your pypirc file, either you type it at the prompt, through a getpass() call. The use case is to be able to store it in a safe place rather than in clear in a config file.
Maybe the new API should just be a utility in distutils?
Sounds like the solution. Although some people might use it to interact with a Keyring without necessarily being in the context of using Distutils, that's why I was targeting a module oustide distutils in the stdlib. Regards, Tarek -- Tarek Ziadé | http://ziade.org
participants (2)
-
Guido van Rossum
-
Tarek Ziadé