Can't fetch password from system

[rgardam]

I am seeing this error on Yosemite (10.10.5 (14F27))

keyring.backends._OS_X_API.Error: (-25293, "Can't fetch password from system")

edit: it works if I enable all applications to use the password from the keychain.

[wlbentley]

Exactly the same error here on El Capitan (10.11.4). Python 2.7 running in a virtualenv.

What does "enable all applications to use the password from the keychain" mean (from @rgardam comment)?

Config root and data root are both reported as /Users/_myusername_/.local/share/python_keyring, but after setting a password with keyring set ..., there is no change to this directory, and no files are created by keyring.

Any suggestions?

[Edit:] When I tried running keyring outside the virtualenv, it works as expected. This is a virtualenv issue.

However, the config and data roots are still being reported as above, and still contain nothing from keyring.

[jaraco]

Keyring doesn't store any passwords in the config or data root for the OS X backend, but instead stores the passwords in the default keychain. After adding a password, you should see changes in the login keychain when running the Keychain Access application.

As for the error message reported or the issues with virtualenv, I'm unable to replicate them.

Last login: Wed May  4 12:41:40 on ttys002
$ python -m virtualenv --version
15.0.1
$ python -m virtualenv --python python2.7 issue219
Running virtualenv with interpreter /usr/bin/python2.7
New python executable in /Users/jaraco/issue219/bin/python
Installing setuptools, pip, wheel...done.
$ issue219/bin/pip install -q -U pip
$ issue219/bin/pip install keyring
Collecting keyring
  Downloading keyring-9.0-py2.py3-none-any.whl
Installing collected packages: keyring
Successfully installed keyring-9.0
$ issue219/bin/keyring set 'test issue 219' 'test user 219'                
Password for 'test user 219' in 'test issue 219': 
$ issue219/bin/keyring get 'test issue 219' 'test user 219'
some password
$ issue219/bin/keyring del 'test issue 219' 'test user 219'
Deleting password for 'test user 219' in 'test issue 219': 

Before deleting the password, I could find it in Keychain Access.

I did not have to do anything special like /enable all applications to use the password from the keychain/.

I'm using OS X El Capitan and Keyring 9.0 on Python 2.7.10.

Can you provide any additional information on what's different about your environment that's different from mine?

[jaraco]

Until I have more information, I don't know what else I can do to help resolve the issue. I do have a clean Mac OS X VM, so if there are steps I can take in that VM to replicate the issue, I'm willing to try. I'm closing the issue for now, but I'm happy to re-open it as new information comes to light.

[n8henrie]

I am getting this error with Python2.7 when using a virtualenv (tox). It works okay with Python2.7 if the venv is deactivated.

I am not getting the error in Python3.4 or Python3.5 in the venv (again, tox) -- they seem to work okay. Strange.

EDIT: Also on OS X 10.11(.5)

EDIT: For each password request, I'm seeing in Console.app (no such message for python3):

2016-05-27 10:17:31.000 PM kernel[0]: CODE SIGNING: cs_invalid_page(0x10454c000): p=52336[python2.7] final status 0x2000000, allowing (remove VALID) page

EDIT: I'm getting it with my pyenv installed 2.7.11:

mkdir tmp
cd tmp
virtualenv -p python2 venv
venv/bin/pip install keyring
venv/bin/python2 -c 'import keyring; print(keyring.get_password("Some Service", "Some Account"))'

As well as OS X's built-in 2.7.10:

mkdir tmp
cd tmp
virtualenv -p /usr/bin/python venv
venv/bin/pip install keyring
venv/bin/python -c 'import keyring; print(keyring.get_password("Some Service", "Some Account"))'

But running fine with my pyenv 3.5.1:

mkdir tmp
cd tmp
virtualenv -p python3 venv
venv/bin/pip install keyring
venv/bin/python -c 'import keyring; print(keyring.get_password("Some Service", "Some Account"))'

[jeremydw]

Data point: this is affecting our program too (https://github.com/grow/grow) and I can confirm it occurs when run in a virtualenv. I can also confirm that downgrading keyring to 8.7 seems to have fixed the issue.

Here's the relevant traceback:

  File "/Users/jeremydw/git/pygrow/env/lib/python2.7/site-packages/oauth2client/keyring_storage.py", line 84, in locked_get
    content = keyring.get_password(self._service_name, self._user_name)
  File "/Users/jeremydw/git/pygrow/env/lib/python2.7/site-packages/keyring/core.py", line 42, in get_password
    return _keyring_backend.get_password(service_name, username)
  File "/Users/jeremydw/git/pygrow/env/lib/python2.7/site-packages/keyring/backends/OS_X.py", line 44, in get_password
    return api.find_generic_password(self.keychain, service, username)
  File "/Users/jeremydw/git/pygrow/env/lib/python2.7/site-packages/keyring/backends/_OS_X_API.py", line 92, in find_generic_password
    NotFound.raise_for_status(status, msg)
  File "/Users/jeremydw/git/pygrow/env/lib/python2.7/site-packages/keyring/backends/_OS_X_API.py", line 43, in raise_for_status
    Error.raise_for_status(status, msg)
  File "/Users/jeremydw/git/pygrow/env/lib/python2.7/site-packages/keyring/backends/_OS_X_API.py", line 35, in raise_for_status
    raise cls(status, msg)
keyring.backends._OS_X_API.Error: (-25293, "Can't fetch password from system")

[jaraco]

Sorry, but I'm still unable to replicate the issue. I created a fresh install of OS X in a virtual machine. Python didn't even have pip installed. This machine is stock. Yet, when I install all the prereqs, keyring works as advertised without any issue:

Jasons-MacBook-Pro:~ jaraco$ sudo python2.7 -m ensurepip

WARNING: Improper use of the sudo command could lead to data loss
or the deletion of important system files. Please double-check your
typing when using sudo. Type "man sudo" for more information.

To proceed, enter your password, or type Ctrl-C to abort.

Password:
The directory '/Users/jaraco/Library/Logs/pip' or its parent directory is not owned by the current user and the debug log has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Ignoring indexes: https://pypi.python.org/simple
The directory '/Users/jaraco/Library/Caches/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Requirement already satisfied (use --upgrade to upgrade): setuptools in /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python
Collecting pip
Installing collected packages: pip
Successfully installed pip-6.1.1
Jasons-MacBook-Pro:~ jaraco$ python2.7 -m pip install --user virtualenv
You are using pip version 6.1.1, however version 8.1.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
Collecting virtualenv
  Downloading virtualenv-15.0.2-py2.py3-none-any.whl (1.8MB)
    100% |████████████████████████████████| 1.8MB 263kB/s 
Installing collected packages: virtualenv
Successfully installed virtualenv
Jasons-MacBook-Pro:~ jaraco$ python2.7 -m virtualenv issue219
New python executable in /Users/jaraco/issue219/bin/python
Installing setuptools, pip, wheel...done.
Jasons-MacBook-Pro:~ jaraco$ issue219/bin/pip install keyring
Collecting keyring
  Downloading keyring-9.0-py2.py3-none-any.whl
Installing collected packages: keyring
Successfully installed keyring-9.0
Jasons-MacBook-Pro:~ jaraco$ issue219/bin/keyring set "Some Service" "Some Account"
Password for 'Some Account' in 'Some Service': 
Jasons-MacBook-Pro:~ jaraco$ issue219/bin/keyring get "Some Service" "Some Account"
some password

It sure seems like whatever is triggering this API error is not universal (and is specific to only some users' systems). Perhaps there's a security setting enabled or a legacy settings lingering from an older build of the OS. I still am aware of no actions that keyring can take to work around the issue, short of bringing back the command-based invocation. I'd consider that, if it's a separate package and not in the default implementation.

I'd prefer, though, if we could understand the underlying cause of the error and correct for it, so any details you might be able to provide as to why your systems are failing and a stock system is not would be most helpful in advancing this issue.

[n8henrie]

Slight update: If I request a password that doesn't exist (by changing a letter of either the service or account), I get None. Only getting the error if requesting an existing password.

[jeremydw]

@jaraco thanks for working through this with us. I just reproduced the error inside virtualenv following your commands exactly (minus the initial ensurepip). See below. Let me know if there's anything else you'd like me to try.

Here's my OS version, if it helps:
Mac OS X El Capitan
10.11.4 (15E65)

$ virtualenv --version
15.0.2

~$ python2.7 -m virtualenv issue219
New python executable in issue219/bin/python
Installing setuptools, pip, wheel...done.
~$ issue219/bin/pip install keyring
Collecting keyring
  Using cached keyring-9.0-py2.py3-none-any.whl
Installing collected packages: keyring
Successfully installed keyring-9.0
You are using pip version 7.1.2, however version 8.1.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
~$ issue219/bin/keyring set "Some Service" "Some Account"
Password for 'Some Account' in 'Some Service': 
~$ issue219/bin/keyring get "Some Service" "Some Account"
Traceback (most recent call last):
  File "issue219/bin/keyring", line 11, in <module>
    sys.exit(main())
  File "/Users/jeremydw/issue219/lib/python2.7/site-packages/keyring/cli.py", line 101, in main
    return cli.run(argv)
  File "/Users/jeremydw/issue219/lib/python2.7/site-packages/keyring/cli.py", line 54, in run
    password = get_password(service, username)
  File "/Users/jeremydw/issue219/lib/python2.7/site-packages/keyring/core.py", line 42, in get_password
    return _keyring_backend.get_password(service_name, username)
  File "/Users/jeremydw/issue219/lib/python2.7/site-packages/keyring/backends/OS_X.py", line 44, in get_password
    return api.find_generic_password(self.keychain, service, username)
  File "/Users/jeremydw/issue219/lib/python2.7/site-packages/keyring/backends/_OS_X_API.py", line 92, in find_generic_password
    NotFound.raise_for_status(status, msg)
  File "/Users/jeremydw/issue219/lib/python2.7/site-packages/keyring/backends/_OS_X_API.py", line 43, in raise_for_status
    Error.raise_for_status(status, msg)
  File "/Users/jeremydw/issue219/lib/python2.7/site-packages/keyring/backends/_OS_X_API.py", line 35, in raise_for_status
    raise cls(status, msg)
keyring.backends._OS_X_API.Error: (-25293, "Can't fetch password from system")
~$ 

[jeremydw]

Worked with keyring==8.7, same system and sequence of commands:

~$ python2.7 -m virtualenv issue219-8.7
New python executable in issue219-8.7/bin/python
Installing setuptools, pip, wheel...done.
~$ issue219-8.7/bin/pip install keyring==8.7
Collecting keyring==8.7
  Using cached keyring-8.7-py2.py3-none-any.whl
Installing collected packages: keyring
Successfully installed keyring-8.7
You are using pip version 7.1.2, however version 8.1.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
~$ issue219-8.7/bin/keyring set "Some Service" "Some Account"
Password for 'Some Account' in 'Some Service': 
~$ issue219-8.7/bin/keyring get "Some Service" "Some Account"
foo
~$ 

[jialongl]

I get this error too after I upgraded to OS X 10.11.5 today, which may or may not have to do with the error. I am not sure.

Quoting @n8henrie :

If I request a password that doesn't exist (by changing a letter of either the service or account), I get None. Only getting the error if requesting an existing password.

And I will not get an error (exception) if I "allow all application to access this item" in OS X Keychain Access.app

So I guess it is a permission thing. That is to say we need to find the correct application to allow access to the item.

Unfortunately, none of those worked...
But hopefully this sheds some light.