Ned Deily added the comment: Update: the MacPorts certsync daemon has matured and is now included as an optional MacPorts port.
It's not a perfect solution as noted in the macports-devel thread: >>The only catch is that custom added certificates or trust anchors need >>to be in the system keychain to be picked up by certsync by default. >Yeah, this was an unfortunate trade-off; since certsync is a system-wide >daemon, and the resulting CA certs file is also system-wide, it seemed to >be the most appropriate course of action. Most of the alternatives involve >patching OpenSSL and some of the software that depends on it, which is a >road I'm personally wary of committing to. http://comments.gmane.org/gmane.os.apple.macports.devel/22653 It works by registering a launchd agent that is run whenever any of the system keychain files or trust setting files are modified. That raises the issues of when and how a Python install should register the agent (will likely need admin/root privileges to do that) and how to delete the agent (we currently don't have a formal uninstall procedure on OS X). It would be easier to manage these things with the binary installer-based Pythons, as provided by python.org, in which case Pythons built by users from source would still use the deprecated Apple-supplied libssl and libcrypto. But I'd like to separate out the building of third-party libraries, like openssl, from the installer build process so that user source builds can take advantage of features like this. ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17128> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
