[Openstack] Keyring support in openstack
Team, As per patch https://review.openstack.org/#/c/9497/ we are adding keyring support for openstack client. If password is not specified in command line or environment variable, the user is prompted to enter password. During this time, the password is stored in keyring. During next time, the password is read from keyring, instead of prompt. It is true, if password is not specified in command line or environment variable. This behavior is documented in this wiki page: http://wiki.openstack.org/KeyringSupport If you have any comments, please let us know. Thank you, -- Regards, Bhuvaneswaran A www.livecipher.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keyring support in openstack
On Mon, Jul 30, 2012 at 6:31 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: You've already answered several of my questions on the ticket, but I still have some usability concerns. How does the keyring system support a single person logging in using multiple user accounts? For example, if I have an admin account and a regular user, how do I switch between them based on the operations I need to perform? The password is stored in keyring, for a given user. It also support multiple users. The password is stored against the user specified in command line, --os-username or environment variable OS_USERNAME. The sample content of the keyring file ~/.openstack-keyring.cfg is as follows: [openstack] bhuvan = dG4wN2FjxA== test = xYwN2FjxA== Is there a way to disable the behavior of having a password saved to a keyring for a particular user, without uninstalling the python-keyring package (and therefore disabling keyring support for all users)? The simplest alternative is to specify password using other mechanism, in command line or environment variable. It's not possible to prevent using keyring, if password is not specified in any of these 2 mechanisms. The purpose of this patch is, to prevent password prompt. The wiki mentions the password being saved using keyring.backend.UncryptedFileKeyring. Does that mean the password is saved in cleartext? Is the file protected in some way besides filesystem permissions? As mentioned in wiki page, the password is stored in base64 format. The mention of one backend implies that there are others. Should we give users a way to choose the backend, in case they have a preference? python-keyring also support several other backends: 1.CryptedFileKeyring 2. GnomeKeyring 3. KDEKWallet 4. OSXKeychain 5. Win32CryptoKeyring 6. ... and more. The behaviour of these backends vary for each desktop. For instance, GnomeKeyring may prompt for keyring password, once per login session. CryptedFileKeyring may prompt for keyring password, every time. It's as good as not using keyring. How does the use of the keyring affect scripting using the command line tool? Can a script access the keyring, or does it need to use the other options? Yes. The script could be managed with any python script, using the same methods exposed in keyring python module. -- get_password() -- to get the password for given user. -- set_password() -- to set the password in keyring. In one review comment you mention a few desktop apps that know how to manipulate the keyring to manage its contents. What about remote access via ssh, where a desktop environment is not available? Does the keyring library include tools for manipulating the file, or do we need to build our own? If so, what tools would be needed? This was applicable for older patch, wherein we rely on desktop/environment specific backend. With older patch, if GNOME desktop is used, GnomeKeyring backend is used; if no desktop is used, CryptedFileKeyring backend is used. With new patch, irrespective of whether desktop is enabled, UncryptedFileKeyring backend is used. With this patch, the keyring behaviour is uniform across all systems in which we deploy openstack. In summary, the primary goal of this patch is to reuse the password entered in the prompt once, and prevent the user from entering the password again. Ultimately, the password is not exposed in environment or command line (ps). It also facilitate the automated script wherein the openstack client might be used. In such case, the password is not read from prompt, but from keyring. -- Regards, Bhuvaneswaran A www.livecipher.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Default reply to behavior for mailing list
Stefano, If a subscriber reply to a mailing list message, it's sent to the author only. Each subscriber should use Reply to All every time, to post a reply to mailing list. Can you please configure the mailing list and set reply-to header as mailing list address, openstack@lists.launchpad.net. With this setup, if the user click reply in his email client, the message is sent to mailing list, instead of the author. Thank you, -- Regards, Bhuvaneswaran A www.livecipher.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default reply to behavior for mailing list
On Tue, Jul 31, 2012 at 1:13 PM, Alex Glikson glik...@il.ibm.com wrote: This discussion invariably turns up on most open source mailing lists from time to time. People never agree on the best setting. Asking for this reply-to setting to be changed is merely shifting the pain away from one set of users (which includes you) onto other set of users (which includes me). There's no net gain here. Just shifting the pain. As such IMHO we should leave it as it is. Is it possible to configure the behavior per user? I have found several threads raising the need for such a feature, but don't know if anyone actually bothered to implement it (seems to be rather straightforward). I'm sure Launchpad doesn't support user level configuration, to edit email headers. -- Regards, Bhuvaneswaran A www.livecipher.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keyring support in openstack
On Mon, Jul 30, 2012 at 5:48 PM, Adam Young ayo...@redhat.com wrote: On 07/30/2012 06:00 PM, Doug Hellmann wrote: On Mon, Jul 30, 2012 at 5:30 PM, Adam Young ayo...@redhat.com wrote: On 07/30/2012 05:17 PM, Kevin L. Mitchell wrote: On Mon, 2012-07-30 at 13:50 -0700, Bhuvaneswaran A wrote: The wiki mentions the password being saved using keyring.backend.UncryptedFileKeyring. Does that mean the password is saved in cleartext? Is the file protected in some way besides filesystem permissions? As mentioned in wiki page, the password is stored in base64 format. Which means it's stored in cleartext. That is Not Good(tm) :) Can Keyring be used to store a token instead? That would A) be better than password and B) avoid a Keystone hit. Don't tokens expire? Yes, they do, but that is no reason not to put them in the keyring, With the PKI tokens, you will be able to query a token's expiry without going across the wire. Adam, can you please file a ticket to use keyring to store tokens for keystone? I'll work on it. -- Regards, Bhuvaneswaran A www.livecipher.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keyring support in openstack
On Mon, Jul 30, 2012 at 2:30 PM, Doug Hellmann doug.hellm...@dreamhost.comwrote: On Mon, Jul 30, 2012 at 4:51 PM, Bhuvaneswaran A bhu...@apache.orgwrote: On Mon, Jul 30, 2012 at 7:46 AM, David Kranz david.kr...@qrclab.com wrote: I share Doug's concerns but would state some more strongly. IMO, it is simply unacceptable to modify user-visible behavior based on whether some package that happens to be used in an implementation is installed or not. This package is installed on Ubuntu by default and may be used by other applications that have nothing to do with OpenStack at all. Yes, as python-keyring is installed in almost all systems, the behaviour is unchanged. If we really want to go down this road there should be an environment variable that can be set to turn off this behavior for applications that do not want it. David, good point. I'll revise the patch to not use keyring, if environment variable USE_KEYRING=0. If environment variable is not set or if it is USE_KEYRING=1, then keyring is used to store password. How about OS_USE_KEYRING so it is clearer that the variable is related to openstack? Just to close the loop ... Doug, thank you for all the review comments. The patch to store encrypted password in keyring, for openstackclient, is merged today: I''ll extend this feature to other clients that prompt for password, like keystoneclient. https://review.openstack.org/#/c/9497/ It's also documented here: http://wiki.openstack.org/KeyringSupport -- Regards, Bhuvaneswaran A www.livecipher.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keyring support in openstack
On Thu, Aug 23, 2012 at 7:10 AM, Scott Moser smo...@ubuntu.com wrote: . [backend] default-keyring=keyring.backend.UncryptedFileKeyring keyring-path=/home/ubuntu/xxx # this is ignored As you might already know, the keyring.backend.UncryptedFileKeyring will store the password as in base64 format. If you are concerned about security, but wouldn't wish to enter keyring password, you might use openstackclient.common.openstackkeyring backend. As part of this patch, we have written a keyring backend for openstack to store encrypted password in keyring, withouth prompting for keyring password. -- Regards, Bhuvaneswaran A www.livecipher.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack-poc] [Bug 976267] Re: auto generate AUTHORS for packaging
Mark, ?? Can you please explain why you set it as Fix committed even though the patch should go in few more projects? ** Changed in: nova Assignee: (unassigned) = Bhuvaneswaran A (bhuvan) -- You received this bug notification because you are a member of OpenStack Common Drivers, which is the registrant for openstack-common. https://bugs.launchpad.net/bugs/976267 Title: auto generate AUTHORS for packaging Status in OpenStack Dashboard (Horizon): New Status in OpenStack Compute (Nova): New Status in openstack-common: Fix Committed Status in OpenStack Object Storage (Swift): New Bug description: As discussed in bug 920757, the check-ins for all projects are gated using CLA sign. It's not necessary to enforce an entry in AUTHORS file. The file should be auto-generated when we package using python setup.py sdist command. The .mailmap file, if exists, should be honored. This is applicable for all projects, swift, keystone, nova and glance. Once this is resolved, we could remove the test, test_authors.py that check for an entry in AUTHORS file. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/976267/+subscriptions ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
[Openstack-poc] [Bug 976267] Re: auto generate AUTHORS for packaging
Mark, nevermind. I got it. -- You received this bug notification because you are a member of OpenStack Common Drivers, which is the registrant for openstack-common. https://bugs.launchpad.net/bugs/976267 Title: auto generate AUTHORS for packaging Status in OpenStack Dashboard (Horizon): New Status in OpenStack Compute (Nova): New Status in openstack-common: Fix Committed Status in OpenStack Object Storage (Swift): New Bug description: As discussed in bug 920757, the check-ins for all projects are gated using CLA sign. It's not necessary to enforce an entry in AUTHORS file. The file should be auto-generated when we package using python setup.py sdist command. The .mailmap file, if exists, should be honored. This is applicable for all projects, swift, keystone, nova and glance. Once this is resolved, we could remove the test, test_authors.py that check for an entry in AUTHORS file. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/976267/+subscriptions ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
[Openstack-poc] [Bug 994957] Re: handle all mailmap with name and email address
** Changed in: openstack-common Status: In Progress = Fix Committed -- You received this bug notification because you are a member of OpenStack Common Drivers, which is the registrant for openstack-common. https://bugs.launchpad.net/bugs/994957 Title: handle all mailmap with name and email address Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Identity (Keystone): Triaged Status in OpenStack Compute (Nova): New Status in openstack-common: In Progress Bug description: The parse_mailmap() method handle following format: em...@foo.com em...@bar.com It can't handle following formats: Foo em...@foo.com Bar em...@bar.com Foo ZZ em...@foo.com Bar YY em...@bar.com All 3 formats are valid mailmap formats, as per this document. http://man.github.com/git/git-shortlog.html Please fix it. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/994957/+subscriptions ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
