** Description changed: [Impact] Some users have reported problems with corrupted keyrings, both in Gnome and KDE, when newlines are included in the password. This makes all launchpadlib-based apps unusable for affected users. The corruption occurs because launchpadlib attempts to store a multi- line value in the keyring, but the keyring service appears to assume values are single-lined, so chokes when it encounters launchpadlib's entries. [Workaround] Delete the keyring (e.g. via 'seahorse') prior to running a launchpadlib-based script. [Development Fix] Upstream version 1.9.12 resolves the issue by base64 encoding the serialized value: - Properly handle Unicode passwords if returned by the keyring. - Base 64 encode serialized credentials before putting in keyring/wallet. [Stable Fix] For the SRU to natty and oneiric, it is proposed to cherrypick the encoding change to credentials.py and its associated test code in test_credential_store.py. [Test Case] - (*TODO*: detailed instructions how to reproduce the bug. These should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem.) + 1. Run a launchpadlib client that uses the keyring + 2. [Optional] Open the key in seahorse, (and optionally ensure there is a newline) then close seahorse + 3. Run the same launchlib client a second time + 4. A "ConfigParser.NoOptionError" will be printed [Regression Potential] - (*TODO*: A discussion of likelihood and potential severity of regressions and how users could get inadvertently affected goes here. ) + Low/none. When there is a corrupted key ring entry, this just reauthorizes and overwrite the old entry, same as if it had expired. [Original Report] Running lp:svammel to do a dry run mass bugfiling against LP, I get prompted to authorize my system to connect to launchpad, which is neat. But on a subsequent invocation of the tool, it fails with: Traceback (most recent call last): File "file-failures.py", line 50, in <module> init(args.serviceroot, 'testing', '~/.launchpadlib/cache/') File "/home/vorlon/devel/linaro/svammel/config.py", line 96, in init set_launchpad(service_root, appid, cachedir) File "/home/vorlon/devel/linaro/svammel/config.py", line 72, in set_launchpad lp = Launchpad.login_with(appid, root, cachedir) File "/usr/lib/pymodules/python2.7/launchpadlib/launchpad.py", line 538, in login_with credential_save_failed, version) File "/usr/lib/pymodules/python2.7/launchpadlib/launchpad.py", line 341, in _authorize_token_and_login authorization_engine.unique_consumer_id) File "/usr/lib/pymodules/python2.7/launchpadlib/credentials.py", line 273, in load return self.do_load(unique_key) File "/usr/lib/pymodules/python2.7/launchpadlib/credentials.py", line 322, in do_load return Credentials.from_string(credential_string) File "/usr/lib/pymodules/python2.7/launchpadlib/credentials.py", line 89, in from_string credentials.load(StringIO(value)) File "/usr/lib/python2.7/dist-packages/lazr/restfulclient/authorize/oauth.py", line 165, in load CREDENTIALS_FILE_VERSION, 'consumer_key') File "/usr/lib/python2.7/ConfigParser.py", line 610, in get raise NoOptionError(option, section) ConfigParser.NoOptionError: No option 'consumer_key' in section: '1' At James Westby's suggestion, I had a peek inside gnome-keyring with seahorse and found this as the 'password' value of the 'network password' token: [1] Presumably there should be a real password here instead. :) People experiencing this problem can work around it by opening their gnome keyring, and deleting the broken password.
** Description changed: [Impact] Some users have reported problems with corrupted keyrings, both in Gnome and KDE, when newlines are included in the password. This makes all launchpadlib-based apps unusable for affected users. The corruption occurs because launchpadlib attempts to store a multi- line value in the keyring, but the keyring service appears to assume values are single-lined, so chokes when it encounters launchpadlib's entries. [Workaround] Delete the keyring (e.g. via 'seahorse') prior to running a launchpadlib-based script. [Development Fix] - Upstream version 1.9.12 resolves the issue by base64 encoding the serialized value: + Upstream version 1.9.12 resolves the issue (and another related bug involving unicode data) by base64 encoding the serialized value: - Properly handle Unicode passwords if returned by the keyring. - Base 64 encode serialized credentials before putting in keyring/wallet. [Stable Fix] For the SRU to natty and oneiric, it is proposed to cherrypick the encoding change to credentials.py and its associated test code in test_credential_store.py. [Test Case] 1. Run a launchpadlib client that uses the keyring 2. [Optional] Open the key in seahorse, (and optionally ensure there is a newline) then close seahorse 3. Run the same launchlib client a second time 4. A "ConfigParser.NoOptionError" will be printed [Regression Potential] Low/none. When there is a corrupted key ring entry, this just reauthorizes and overwrite the old entry, same as if it had expired. [Original Report] Running lp:svammel to do a dry run mass bugfiling against LP, I get prompted to authorize my system to connect to launchpad, which is neat. But on a subsequent invocation of the tool, it fails with: Traceback (most recent call last): File "file-failures.py", line 50, in <module> init(args.serviceroot, 'testing', '~/.launchpadlib/cache/') File "/home/vorlon/devel/linaro/svammel/config.py", line 96, in init set_launchpad(service_root, appid, cachedir) File "/home/vorlon/devel/linaro/svammel/config.py", line 72, in set_launchpad lp = Launchpad.login_with(appid, root, cachedir) File "/usr/lib/pymodules/python2.7/launchpadlib/launchpad.py", line 538, in login_with credential_save_failed, version) File "/usr/lib/pymodules/python2.7/launchpadlib/launchpad.py", line 341, in _authorize_token_and_login authorization_engine.unique_consumer_id) File "/usr/lib/pymodules/python2.7/launchpadlib/credentials.py", line 273, in load return self.do_load(unique_key) File "/usr/lib/pymodules/python2.7/launchpadlib/credentials.py", line 322, in do_load return Credentials.from_string(credential_string) File "/usr/lib/pymodules/python2.7/launchpadlib/credentials.py", line 89, in from_string credentials.load(StringIO(value)) File "/usr/lib/python2.7/dist-packages/lazr/restfulclient/authorize/oauth.py", line 165, in load CREDENTIALS_FILE_VERSION, 'consumer_key') File "/usr/lib/python2.7/ConfigParser.py", line 610, in get raise NoOptionError(option, section) ConfigParser.NoOptionError: No option 'consumer_key' in section: '1' At James Westby's suggestion, I had a peek inside gnome-keyring with seahorse and found this as the 'password' value of the 'network password' token: [1] Presumably there should be a real password here instead. :) People experiencing this problem can work around it by opening their gnome keyring, and deleting the broken password. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/745801 Title: system-based authorization broken in gnome-keyring: NoOptionError: No option 'consumer_key' in section: '1' To manage notifications about this bug go to: https://bugs.launchpad.net/launchpadlib/+bug/745801/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
