Activity log for bug #1864204

Date Who What changed Old value New value Message
2020-02-21 15:07:24 Dan Streetman bug added bug
2020-02-21 15:07:45 Dan Streetman bug watch added https://github.com/jaraco/keyring/issues/372
2020-02-21 15:07:45 Dan Streetman bug task added python-keyring
2020-02-21 15:07:58 Dan Streetman python-keyring (Ubuntu): importance Undecided Medium
2020-02-21 15:26:36 Bug Watch Updater python-keyring: status Unknown New
2020-02-21 15:38:51 Dan Streetman description [impact] when no backends are available for python-keyring, it will sometimes silently ignore all requests to set or get credentials, and sometimes it will raise RuntimeError for all requests. [test case] when there are no backends, there are 2 built-in backends that will be the only ones available, the 'chainer' backend and the 'fail' backend. The 'fail' backend always has priority 0, while the 'chainer' backend has priority 10 if it contains any actual backends, and priority 0 if it is empty. So in the situtation where there are no actual backends, both 'chainer' and 'fail' will have priority 0. Since the 'backends' class stores its backend implementation instances in a python set(), which is unordered, it is non-deterministic which of those backends are used at any given time. Since the behavior is non-deterministic, simply trying this multiple times may result in each behavior. Rebooting or logout/login can help 'switch' the behavior. >>> import keyring >>> [keyring.backend.get_all_keyring()] the above python code will show the current list of backends, and since they both have the same priority (in this situation) the first in the list will be used. If the list looks like: [[<keyring.backends.chainer.ChainerBackend object at 0x7f1f7018f3d0>, <keyring.backends.fail.Keyring object at 0x7f1f6fff0820>]] with 'ChainerBackend' first, all keyring functions will return silently with None, e.g.: >>> keyring.set_password('test', 'test', 'test') >>> keyring.get_password('test', 'test') >>> with 'fail.Keyring' first, all keyring functions will raise RuntimeError: >>> import keyring >>> [keyring.backend.get_all_keyring()] [[<keyring.backends.fail.Keyring object at 0x7f3b6ade73d0>, <keyring.backends.chainer.ChainerBackend object at 0x7f3b6ac48820>]] >>> keyring.set_password('test', 'test', 'test') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python3/dist-packages/keyring/core.py", line 63, in set_password _keyring_backend.set_password(service_name, username, password) File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. >>> keyring.get_password('test', 'test') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python3/dist-packages/keyring/core.py", line 57, in get_password return _keyring_backend.get_password(service_name, username) File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. [regression potential] TBD as this is still an upstream bug [scope] this still affects upstream, as well as all Debian and Ubuntu releases [other info] this affects any application that uses the python-launchpadlib library, as that internally uses keyrings. [impact] when no backends are available for python-keyring, it will sometimes silently ignore all requests to set or get credentials, and sometimes it will raise RuntimeError for all requests. [test case] when there are no backends, there are 2 built-in backends that will be the only ones available, the 'chainer' backend and the 'fail' backend. The 'fail' backend always has priority 0, while the 'chainer' backend has priority 10 if it contains any actual backends, and priority 0 if it is empty. So in the situtation where there are no actual backends, both 'chainer' and 'fail' will have priority 0. Since the 'backends' class stores its backend implementation instances in a python set(), which is unordered, it is non-deterministic which of those backends are used at any given time. Since the behavior is non-deterministic, simply trying this multiple times may result in each behavior. Rebooting or logout/login can help 'switch' the behavior. >>> import keyring >>> [keyring.backend.get_all_keyring()] the above python code will show the current list of backends, and since they both have the same priority (in this situation) the first in the list will be used. If the list looks like: [[<keyring.backends.chainer.ChainerBackend object at 0x7f1f7018f3d0>, <keyring.backends.fail.Keyring object at 0x7f1f6fff0820>]] with 'ChainerBackend' first, all keyring functions will return silently with None, e.g.: >>> keyring.set_password('test', 'test', 'test') >>> keyring.get_password('test', 'test') >>> with 'fail.Keyring' first, all keyring functions will raise RuntimeError: >>> import keyring >>> [keyring.backend.get_all_keyring()] [[<keyring.backends.fail.Keyring object at 0x7f3b6ade73d0>, <keyring.backends.chainer.ChainerBackend object at 0x7f3b6ac48820>]] >>> keyring.set_password('test', 'test', 'test') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib/python3/dist-packages/keyring/core.py", line 63, in set_password     _keyring_backend.set_password(service_name, username, password)   File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password     raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. >>> keyring.get_password('test', 'test') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib/python3/dist-packages/keyring/core.py", line 57, in get_password     return _keyring_backend.get_password(service_name, username)   File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password     raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. [regression potential] TBD as this is still an upstream bug [scope] This affects Eoan and later, including upstream. This does not affect Bionic or earlier, as they do not have the commit that introduces the bug. this was introduced upstream by commit 0114733e91f249246c8fec9e659cd7ba2388ea0d which was first included in version 16.1.0. [other info] this affects any application that uses the python-launchpadlib library, as that internally uses keyrings.
2020-02-21 15:39:24 Dan Streetman nominated for series Ubuntu Eoan
2020-02-21 15:39:24 Dan Streetman bug task added python-keyring (Ubuntu Eoan)
2020-02-21 15:39:24 Dan Streetman nominated for series Ubuntu Focal
2020-02-21 15:39:24 Dan Streetman bug task added python-keyring (Ubuntu Focal)
2020-02-21 15:39:35 Dan Streetman python-keyring (Ubuntu Eoan): importance Undecided Medium
2020-02-21 18:36:59 Dan Streetman bug task added python-launchpadlib (Ubuntu)
2020-02-21 18:37:10 Dan Streetman python-launchpadlib (Ubuntu Eoan): importance Undecided Medium
2020-02-21 18:37:11 Dan Streetman python-launchpadlib (Ubuntu Focal): importance Undecided Medium
2020-02-22 17:50:50 Dan Streetman description [impact] when no backends are available for python-keyring, it will sometimes silently ignore all requests to set or get credentials, and sometimes it will raise RuntimeError for all requests. [test case] when there are no backends, there are 2 built-in backends that will be the only ones available, the 'chainer' backend and the 'fail' backend. The 'fail' backend always has priority 0, while the 'chainer' backend has priority 10 if it contains any actual backends, and priority 0 if it is empty. So in the situtation where there are no actual backends, both 'chainer' and 'fail' will have priority 0. Since the 'backends' class stores its backend implementation instances in a python set(), which is unordered, it is non-deterministic which of those backends are used at any given time. Since the behavior is non-deterministic, simply trying this multiple times may result in each behavior. Rebooting or logout/login can help 'switch' the behavior. >>> import keyring >>> [keyring.backend.get_all_keyring()] the above python code will show the current list of backends, and since they both have the same priority (in this situation) the first in the list will be used. If the list looks like: [[<keyring.backends.chainer.ChainerBackend object at 0x7f1f7018f3d0>, <keyring.backends.fail.Keyring object at 0x7f1f6fff0820>]] with 'ChainerBackend' first, all keyring functions will return silently with None, e.g.: >>> keyring.set_password('test', 'test', 'test') >>> keyring.get_password('test', 'test') >>> with 'fail.Keyring' first, all keyring functions will raise RuntimeError: >>> import keyring >>> [keyring.backend.get_all_keyring()] [[<keyring.backends.fail.Keyring object at 0x7f3b6ade73d0>, <keyring.backends.chainer.ChainerBackend object at 0x7f3b6ac48820>]] >>> keyring.set_password('test', 'test', 'test') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib/python3/dist-packages/keyring/core.py", line 63, in set_password     _keyring_backend.set_password(service_name, username, password)   File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password     raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. >>> keyring.get_password('test', 'test') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib/python3/dist-packages/keyring/core.py", line 57, in get_password     return _keyring_backend.get_password(service_name, username)   File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password     raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. [regression potential] TBD as this is still an upstream bug [scope] This affects Eoan and later, including upstream. This does not affect Bionic or earlier, as they do not have the commit that introduces the bug. this was introduced upstream by commit 0114733e91f249246c8fec9e659cd7ba2388ea0d which was first included in version 16.1.0. [other info] this affects any application that uses the python-launchpadlib library, as that internally uses keyrings. [impact] when no backends are available for python-keyring, it will sometimes silently ignore all requests to set or get credentials, and sometimes it will raise RuntimeError for all requests. [test case] when there are no backends, there are 2 built-in backends that will be the only ones available, the 'chainer' backend and the 'fail' backend. The 'fail' backend always has priority 0, while the 'chainer' backend has priority 10 if it contains any actual backends, and priority 0 if it is empty. So in the situtation where there are no actual backends, both 'chainer' and 'fail' will have priority 0. Since the 'backends' class stores its backend implementation instances in a python set(), which is unordered, it is non-deterministic which of those backends are used at any given time. Since the behavior is non-deterministic, simply trying this multiple times may result in each behavior. Rebooting or logout/login can help 'switch' the behavior. >>> import keyring >>> [keyring.backend.get_all_keyring()] the above python code will show the current list of backends, and since they both have the same priority (in this situation) the first in the list will be used. If the list looks like: [[<keyring.backends.chainer.ChainerBackend object at 0x7f1f7018f3d0>, <keyring.backends.fail.Keyring object at 0x7f1f6fff0820>]] with 'ChainerBackend' first, all keyring functions will return silently with None, e.g.: >>> keyring.set_password('test', 'test', 'test') >>> keyring.get_password('test', 'test') >>> with 'fail.Keyring' first, all keyring functions will raise RuntimeError: >>> import keyring >>> [keyring.backend.get_all_keyring()] [[<keyring.backends.fail.Keyring object at 0x7f3b6ade73d0>, <keyring.backends.chainer.ChainerBackend object at 0x7f3b6ac48820>]] >>> keyring.set_password('test', 'test', 'test') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib/python3/dist-packages/keyring/core.py", line 63, in set_password     _keyring_backend.set_password(service_name, username, password)   File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password     raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. >>> keyring.get_password('test', 'test') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib/python3/dist-packages/keyring/core.py", line 57, in get_password     return _keyring_backend.get_password(service_name, username)   File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password     raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. [regression potential] TBD as this is still an upstream bug [scope] This affects Eoan and later, including upstream. This does not affect Bionic or earlier, as they do not have the commit that introduces the bug. this was introduced upstream by commit 0114733e91f249246c8fec9e659cd7ba2388ea0d which was first included in version 16.1.0. [other info] this affects any application that uses the python-launchpadlib library, as that internally uses keyrings. Opened upstream PR to at least make the behavior deterministic: https://github.com/jaraco/keyring/pull/424 Also adds new 'NoKeyringError' so callers can catch that specific error instead of raising generic RuntimeError.
2020-02-22 17:52:29 Dan Streetman description [impact] when no backends are available for python-keyring, it will sometimes silently ignore all requests to set or get credentials, and sometimes it will raise RuntimeError for all requests. [test case] when there are no backends, there are 2 built-in backends that will be the only ones available, the 'chainer' backend and the 'fail' backend. The 'fail' backend always has priority 0, while the 'chainer' backend has priority 10 if it contains any actual backends, and priority 0 if it is empty. So in the situtation where there are no actual backends, both 'chainer' and 'fail' will have priority 0. Since the 'backends' class stores its backend implementation instances in a python set(), which is unordered, it is non-deterministic which of those backends are used at any given time. Since the behavior is non-deterministic, simply trying this multiple times may result in each behavior. Rebooting or logout/login can help 'switch' the behavior. >>> import keyring >>> [keyring.backend.get_all_keyring()] the above python code will show the current list of backends, and since they both have the same priority (in this situation) the first in the list will be used. If the list looks like: [[<keyring.backends.chainer.ChainerBackend object at 0x7f1f7018f3d0>, <keyring.backends.fail.Keyring object at 0x7f1f6fff0820>]] with 'ChainerBackend' first, all keyring functions will return silently with None, e.g.: >>> keyring.set_password('test', 'test', 'test') >>> keyring.get_password('test', 'test') >>> with 'fail.Keyring' first, all keyring functions will raise RuntimeError: >>> import keyring >>> [keyring.backend.get_all_keyring()] [[<keyring.backends.fail.Keyring object at 0x7f3b6ade73d0>, <keyring.backends.chainer.ChainerBackend object at 0x7f3b6ac48820>]] >>> keyring.set_password('test', 'test', 'test') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib/python3/dist-packages/keyring/core.py", line 63, in set_password     _keyring_backend.set_password(service_name, username, password)   File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password     raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. >>> keyring.get_password('test', 'test') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib/python3/dist-packages/keyring/core.py", line 57, in get_password     return _keyring_backend.get_password(service_name, username)   File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password     raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. [regression potential] TBD as this is still an upstream bug [scope] This affects Eoan and later, including upstream. This does not affect Bionic or earlier, as they do not have the commit that introduces the bug. this was introduced upstream by commit 0114733e91f249246c8fec9e659cd7ba2388ea0d which was first included in version 16.1.0. [other info] this affects any application that uses the python-launchpadlib library, as that internally uses keyrings. Opened upstream PR to at least make the behavior deterministic: https://github.com/jaraco/keyring/pull/424 Also adds new 'NoKeyringError' so callers can catch that specific error instead of raising generic RuntimeError. [impact] when no backends are available for python-keyring, it will sometimes silently ignore all requests to set or get credentials, and sometimes it will raise RuntimeError for all requests. [test case] when there are no backends, there are 2 built-in backends that will be the only ones available, the 'chainer' backend and the 'fail' backend. The 'fail' backend always has priority 0, while the 'chainer' backend has priority 10 if it contains any actual backends, and priority 0 if it is empty. So in the situtation where there are no actual backends, both 'chainer' and 'fail' will have priority 0. Since the 'backends' class stores its backend implementation instances in a python set(), which is unordered, it is non-deterministic which of those backends are used at any given time. Since the behavior is non-deterministic, simply trying this multiple times may result in each behavior. Rebooting or logout/login can help 'switch' the behavior, although simply re-running the test multiple times should be enough to eventually test both backends. >>> import keyring >>> [keyring.backend.get_all_keyring()] the above python code will show the current list of backends, and since they both have the same priority (in this situation) the first in the list will be used. If the list looks like: [[<keyring.backends.chainer.ChainerBackend object at 0x7f1f7018f3d0>, <keyring.backends.fail.Keyring object at 0x7f1f6fff0820>]] with 'ChainerBackend' first, all keyring functions will return silently with None, e.g.: >>> keyring.set_password('test', 'test', 'test') >>> keyring.get_password('test', 'test') >>> with 'fail.Keyring' first, all keyring functions will raise RuntimeError: >>> import keyring >>> [keyring.backend.get_all_keyring()] [[<keyring.backends.fail.Keyring object at 0x7f3b6ade73d0>, <keyring.backends.chainer.ChainerBackend object at 0x7f3b6ac48820>]] >>> keyring.set_password('test', 'test', 'test') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib/python3/dist-packages/keyring/core.py", line 63, in set_password     _keyring_backend.set_password(service_name, username, password)   File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password     raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. >>> keyring.get_password('test', 'test') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib/python3/dist-packages/keyring/core.py", line 57, in get_password     return _keyring_backend.get_password(service_name, username)   File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password     raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. [regression potential] TBD as this is still an upstream bug [scope] This affects Eoan and later, including upstream. This does not affect Bionic or earlier, as they do not have the commit that introduces the bug. this was introduced upstream by commit 0114733e91f249246c8fec9e659cd7ba2388ea0d which was first included in version 16.1.0. [other info] this affects any application that uses the python-launchpadlib library, as that internally uses keyrings. Opened upstream PR to at least make the behavior deterministic: https://github.com/jaraco/keyring/pull/424 Also adds new 'NoKeyringError' so callers can catch that specific error instead of raising generic RuntimeError.
2020-02-27 12:21:21 Launchpad Janitor python-keyring (Ubuntu): status New Confirmed
2020-02-27 12:21:21 Launchpad Janitor python-launchpadlib (Ubuntu): status New Confirmed
2020-02-27 12:21:21 Launchpad Janitor python-keyring (Ubuntu Eoan): status New Confirmed
2020-02-27 12:21:21 Launchpad Janitor python-launchpadlib (Ubuntu Eoan): status New Confirmed
2020-02-27 12:28:48 Dan Streetman python-keyring (Ubuntu Focal): assignee Dan Streetman (ddstreet)
2020-02-27 12:28:49 Dan Streetman python-keyring (Ubuntu Eoan): assignee Dan Streetman (ddstreet)
2020-02-27 12:28:51 Dan Streetman python-launchpadlib (Ubuntu Eoan): assignee Dan Streetman (ddstreet)
2020-02-27 12:28:52 Dan Streetman python-launchpadlib (Ubuntu Focal): assignee Dan Streetman (ddstreet)
2020-02-27 12:28:55 Dan Streetman python-launchpadlib (Ubuntu Focal): status Confirmed In Progress
2020-02-27 12:28:56 Dan Streetman python-launchpadlib (Ubuntu Eoan): status Confirmed In Progress
2020-02-27 12:28:58 Dan Streetman python-keyring (Ubuntu Focal): status Confirmed In Progress
2020-02-27 12:29:00 Dan Streetman python-keyring (Ubuntu Eoan): status Confirmed In Progress
2020-03-14 11:54:27 Dan Streetman description [impact] when no backends are available for python-keyring, it will sometimes silently ignore all requests to set or get credentials, and sometimes it will raise RuntimeError for all requests. [test case] when there are no backends, there are 2 built-in backends that will be the only ones available, the 'chainer' backend and the 'fail' backend. The 'fail' backend always has priority 0, while the 'chainer' backend has priority 10 if it contains any actual backends, and priority 0 if it is empty. So in the situtation where there are no actual backends, both 'chainer' and 'fail' will have priority 0. Since the 'backends' class stores its backend implementation instances in a python set(), which is unordered, it is non-deterministic which of those backends are used at any given time. Since the behavior is non-deterministic, simply trying this multiple times may result in each behavior. Rebooting or logout/login can help 'switch' the behavior, although simply re-running the test multiple times should be enough to eventually test both backends. >>> import keyring >>> [keyring.backend.get_all_keyring()] the above python code will show the current list of backends, and since they both have the same priority (in this situation) the first in the list will be used. If the list looks like: [[<keyring.backends.chainer.ChainerBackend object at 0x7f1f7018f3d0>, <keyring.backends.fail.Keyring object at 0x7f1f6fff0820>]] with 'ChainerBackend' first, all keyring functions will return silently with None, e.g.: >>> keyring.set_password('test', 'test', 'test') >>> keyring.get_password('test', 'test') >>> with 'fail.Keyring' first, all keyring functions will raise RuntimeError: >>> import keyring >>> [keyring.backend.get_all_keyring()] [[<keyring.backends.fail.Keyring object at 0x7f3b6ade73d0>, <keyring.backends.chainer.ChainerBackend object at 0x7f3b6ac48820>]] >>> keyring.set_password('test', 'test', 'test') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib/python3/dist-packages/keyring/core.py", line 63, in set_password     _keyring_backend.set_password(service_name, username, password)   File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password     raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. >>> keyring.get_password('test', 'test') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib/python3/dist-packages/keyring/core.py", line 57, in get_password     return _keyring_backend.get_password(service_name, username)   File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password     raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. [regression potential] TBD as this is still an upstream bug [scope] This affects Eoan and later, including upstream. This does not affect Bionic or earlier, as they do not have the commit that introduces the bug. this was introduced upstream by commit 0114733e91f249246c8fec9e659cd7ba2388ea0d which was first included in version 16.1.0. [other info] this affects any application that uses the python-launchpadlib library, as that internally uses keyrings. Opened upstream PR to at least make the behavior deterministic: https://github.com/jaraco/keyring/pull/424 Also adds new 'NoKeyringError' so callers can catch that specific error instead of raising generic RuntimeError. [impact] when no backends are available for python-keyring, it will sometimes silently ignore all requests to set or get credentials, and sometimes it will raise RuntimeError for all requests. [test case] when there are no backends, there are 2 built-in backends that will be the only ones available, the 'chainer' backend and the 'fail' backend. The 'fail' backend always has priority 0, while the 'chainer' backend has priority 10 if it contains any actual backends, and priority 0 if it is empty. So in the situtation where there are no actual backends, both 'chainer' and 'fail' will have priority 0. Since the 'backends' class stores its backend implementation instances in a python set(), which is unordered, it is non-deterministic which of those backends are used at any given time. Since the behavior is non-deterministic, simply trying this multiple times may result in each behavior. Rebooting or logout/login can help 'switch' the behavior, although simply re-running the test multiple times should be enough to eventually test both backends. >>> import keyring >>> [keyring.backend.get_all_keyring()] the above python code will show the current list of backends, and since they both have the same priority (in this situation) the first in the list will be used. If the list looks like: [[<keyring.backends.chainer.ChainerBackend object at 0x7f1f7018f3d0>, <keyring.backends.fail.Keyring object at 0x7f1f6fff0820>]] with 'ChainerBackend' first, all keyring functions will return silently with None, e.g.: >>> keyring.set_password('test', 'test', 'test') >>> keyring.get_password('test', 'test') >>> with 'fail.Keyring' first, all keyring functions will raise RuntimeError: >>> import keyring >>> [keyring.backend.get_all_keyring()] [[<keyring.backends.fail.Keyring object at 0x7f3b6ade73d0>, <keyring.backends.chainer.ChainerBackend object at 0x7f3b6ac48820>]] >>> keyring.set_password('test', 'test', 'test') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib/python3/dist-packages/keyring/core.py", line 63, in set_password     _keyring_backend.set_password(service_name, username, password)   File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password     raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. >>> keyring.get_password('test', 'test') Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib/python3/dist-packages/keyring/core.py", line 57, in get_password     return _keyring_backend.get_password(service_name, username)   File "/usr/lib/python3/dist-packages/keyring/backends/fail.py", line 24, in get_password     raise RuntimeError(msg) RuntimeError: No recommended backend was available. Install a recommended 3rd party backend package; or, install the keyrings.alt package if you want to use the non-recommended backends. See https://pypi.org/project/keyring for details. [regression potential] And regressions would likely occur when no keyring backends, or only a single keyring backend, are/is availble, since this lowers the priority of the 'chainer' keyring backend, and the intention of this is to fix the existing problem when there is no keyring backend. It should be noted that because the current behavior is non-deterministic, alternating between no error at all and raised RuntimeError, some existing users of python-keyring that occasionally do not see any error (but then also occasionally see RuntimeError raised) will now always see NoKeyringError raised (which does inherit from RuntimeError, to keep backwards compatibility for users that currently catch RuntimeError). That is not actually a regression, since the behavior was non-deterministic; one way had to be chosen, and always raising error when there are no keyring backends is more appropriate than always silently failing when there are no keyring backends. [scope] This affects Eoan and later, including upstream. This does not affect Bionic or earlier, as they do not have the commit that introduces the bug. this was introduced upstream by commit 0114733e91f249246c8fec9e659cd7ba2388ea0d which was first included in version 16.1.0. [other info] this affects any application that uses the python-launchpadlib library, as that internally uses keyrings. Opened upstream PR to at least make the behavior deterministic: https://github.com/jaraco/keyring/pull/424 Also adds new 'NoKeyringError' so callers can catch that specific error instead of raising generic RuntimeError.
2020-03-14 15:04:22 Launchpad Janitor python-keyring (Ubuntu Focal): status In Progress Fix Released
2020-03-20 20:31:00 Brian Murray python-keyring (Ubuntu Eoan): status In Progress Fix Committed
2020-03-20 20:31:06 Brian Murray bug added subscriber Ubuntu Stable Release Updates Team
2020-03-20 20:31:09 Brian Murray bug added subscriber SRU Verification
2020-03-20 20:31:15 Brian Murray tags verification-needed verification-needed-eoan
2020-03-25 19:33:21 Dan Streetman tags verification-needed verification-needed-eoan verification-done verification-done-eoan
2020-03-30 11:14:46 Launchpad Janitor python-keyring (Ubuntu Eoan): status Fix Committed Fix Released
2020-03-30 11:14:50 Łukasz Zemczak removed subscriber Ubuntu Stable Release Updates Team
2020-04-14 11:21:16 Colin Watson branch linked lp:~ddstreet/launchpadlib/nosudo
2020-04-14 11:21:33 Colin Watson bug task added launchpadlib
2020-04-14 11:35:08 Colin Watson launchpadlib: status New Fix Released
2020-04-14 11:35:08 Colin Watson launchpadlib: milestone 1.10.11
2020-04-14 11:35:08 Colin Watson launchpadlib: assignee Dan Streetman (ddstreet)
2020-04-14 11:45:29 Colin Watson launchpadlib: importance Undecided High
2020-04-20 11:55:25 Launchpad Janitor python-launchpadlib (Ubuntu Focal): status In Progress Fix Released
2020-08-18 16:58:26 Brian Murray python-launchpadlib (Ubuntu Eoan): status In Progress Won't Fix