We have four sets of cleartext passwords (http & proxy & db), and secrets such as various API keys and mw cookies and edit tokens.
The passwords are stored in two files in clear text (user-config.py and. passwd). Other secrets are in cached api files, etc.
I would like to introduce an optional dependency on a library to manage (some of?) these secrets. The current secret storage would continue to work correctly.
The keyring package is the obvious candidate. Any objections or improvements on that?
On 15 June 2014 09:19, John Mark Vandenberg jayvdb@gmail.com wrote:
We have four sets of cleartext passwords (http & proxy & db), and secrets such as various API keys and mw cookies and edit tokens.
The passwords are stored in two files in clear text (user-config.py and. passwd). Other secrets are in cached api files, etc.
I would like to introduce an optional dependency on a library to manage
(some of?) these secrets. The current secret storage would continue to work correctly.
The keyring package is the obvious candidate. Any objections or improvements on that?
I'm not completely sure how that would work -- I see how it could work as alternative to ~/.pywikibot, but it might be problematic for people with multiple checkouts for different usernames/bots. In addition, I'm afraid this might make the credential storage fairly opaque: you'd need to run some script to set the password, instead of just editing a config file.
What's the major advantage over a file with 600 permissions? Will it prevent local administrators from accessing the password? (they could also just sniff the password from the network traffic...)
One last point: I think cached api files should *not* store passwords. The exception are the tests, which cache everything to make sure tests run reasonably fast.
Merlijn
On Sun, Jun 15, 2014 at 9:25 PM, Merlijn van Deen valhallasw@arctus.nl wrote:
On 15 June 2014 09:19, John Mark Vandenberg jayvdb@gmail.com wrote:
We have four sets of cleartext passwords (http & proxy & db), and secrets such as various API keys and mw cookies and edit tokens.
The passwords are stored in two files in clear text (user-config.py and. passwd). Other secrets are in cached api files, etc.
I would like to introduce an optional dependency on a library to manage (some of?) these secrets. The current secret storage would continue to work correctly.
The keyring package is the obvious candidate. Any objections or improvements on that?
I'm not completely sure how that would work -- I see how it could work as alternative to ~/.pywikibot, but it might be problematic for people with multiple checkouts for different usernames/bots.
user-config.py would still be the place to store account names; only the passwords would be located somewhere else, in a wallet.
In addition, I'm afraid this might make the credential storage fairly opaque: you'd need to run some script to set the password, instead of just editing a config file.
We currently prompt users to enter their wiki account password. We would do the same if the password is not in the user's wallet, and then store it in the wallet if requested by the user.
There are also programs like KWallet which provide a nice user interface for the wallet.
The wallet is shared, so passwords to utilise a wiki account need only be stored once in order for many applications to reuse it. .
What's the major advantage over a file with 600 permissions?
Currently the proxy and http passwords are placed in user-config.py , which isnt good. That file should be able to be viewed on a computer with other people watching. IMO that needs to be fixed. And if we fix that, we may as well look for a solution which covers wiki passwords/secrets also.
Allowing the backing store to be configurable via keyring will allow the user to put this information where they feel most comfortable storing it, and it may be a protected storage and transit system.
Will it prevent local administrators from accessing the password? (they could also just sniff the password from the network traffic...)
Not if the traffic is SSL, unless they are NSA.
One last point: I think cached api files should *not* store passwords. The exception are the tests, which cache everything to make sure tests run reasonably fast.
Sorry, you are right - the API call for tokens isnt currently cached, except by the tests as you mention.
The cookies are kept in pywikibot.lwp
pywikipedia-l@lists.wikimedia.org