asymmetric.generate_pair fails on Homebrew Python 2.7 + virtualenv

[jviide]

I bumped into a situation similar to #7, where calling asymmetric.generate_pair using Python 2.7 and virtualenv fails with OSError: The user name or passphrase you entered is not correct.. The twist is that I wasn't using the system Python 2.7, but one installed through Homebrew.

The issue can be reproduced by initializing and activating a new virtualenv using python2.7 from Homebrew. It should be noted that in this case Homebrew files aren't in the usual /usr/local path, but inside the test user's home directory.

$ which python2.7
/Users/test/homebrew/bin/python2.7
$ python2.7 -m virtualenv test
$ source test/bin/activate
(test) $ pip2.7 install oscrypto
(test) $ python2.7

Now calling asymmetric.generate_pair in the virtualenv fails:

>>> from oscrypto import asymmetric
>>> asymmetric.generate_pair("rsa", 4096)
Traceback (most recent call last):
  ...
OSError: The user name or passphrase you entered is not correct.

I suspect the problem is related to lines 57-58 in oscrypto/asymmetric.py that check the sys.real_prefix path. In my scenario real_prefix is set, but doesn't begin with _system_prefix:

>>> import sys
>>> sys.real_prefix
'/Users/test/homebrew/Cellar/python/2.7.12/Frameworks/Python.framework/Versions/2.7'

[jviide]

Oh, and the used environment was OS X 10.11.6.

[wbond]

It appears that OS X does not like it when relocated binaries interact with the keychain. It is too bad since I can't seem to find any definitive info on this via basic web searches.

I'll add another check to detect virtualenvs that originated from Homebrew.

I'll also see if the ownership of the original python and virtualenv'ed python makes a difference in terms of the error appearing.

[wbond]

Edit: never mind, I was reading the paths wrong. Homebrew just duplicates system folder names.

[wbond]

Can you tell me if the owner of the two binaries (the original homebrew python2.7 and the virtualenv one) are the same?

I tried to replicate this myself, and was unable to. However, the owner of the homebrew and the virtualenv versions are the same for me.

[jviide]

Yes, the owner of the homebrew and the virtualenv versions are the same for me as well.

[jviide]

Hm, I can't replicate this either if I start with a fresh homebrew directory and install python there - except if I use the exact same name /Users/test/homebrew for the homebrew directory (after removing the old /Users/test/homebrew).

I had previously installed Python 2.7.11 to the old homebrew directory, then updated it to 2.7.12. Could the OSX keychain remember the path /Users/test/homebrew/... + hash (or somesuch) of the old 2.7.11 binary and fail because the updated 2.7.12 version doesn't match the hash?

[wbond]

Alright, hopefully 4aa2817fde92ada601446875e4cb558bf4e48555 should be a general-purpose fix for this odd OS X behavior. It should work until OpenSSL is removed from OS X.

[jviide]

Argh, I'm very sorry: I can't anymore test the specific environment that had this problem.

Looking at 4aa2817fde92ada601446875e4cb558bf4e48555 it looks like it should take care of the problem. Thank you for your patience and sorry for not being able to properly confirm the fix.

[wbond]

Ok, I'll close this. Thanks for taking the time to report this!

[wbond]

For future reference:

• http://lists.apple.com/archives/apple-cdsa/2010/May/msg00014.html
• https://github.com/jaraco/keyring/issues/13
• https://github.com/jaraco/keyring/issues/219