On 10 November 2014 at 22:51, Ned Deily <n...@acm.org> wrote: > In article > <CACgdh2iG9+cLjj7mZ7qeALQd==pcrknnv8i_eerj6ahjvg3...@mail.gmail.com>, > Paul Wiseman <poal...@gmail.com> wrote: > > I've been using the latest mac ppc/i386 binaries from python.org > > (https://www.python.org/ftp/python/2.7.8/python-2.7.8-macosx10.5.dmg). > > From what I can tell this version is linked against a pretty old > > version of OpenSSL (OpenSSL 0.9.7l 28 Sep 2006) which doesn't seem to > > be able to handle new sha-256 certificates. > > > > For example I'm unable to use pip (I guess the certificate was updated > > recently) > > Yes, the current python.org certificate does seem to cause problems for > that version of OpenSSL, unfortunately. > > > Am I right in thinking this is an issue with the build of python > > itself? Is there a way I can upgrade the version of OpenSSL linked > > with python- or force the python build to look elsewhere for the > > library? Or will I have to build my own from source? > > In the Pythons from the python.org OS X installers, the Python _ssl and > _hashlib extension modules are dynamically linked with the > system-supplied OpenSSL libraries. If actually running on OS X 10.5, > one would have to rebuild _ssl.so and _hashlib.so, linking them with a > locally-supplied version of a newer OpenSSL, since different versions of > OpenSSL are not ABI-compatible, e.g. 0.9.7 vs 0.9.8 vs 1.0.1. If > running on OS X 10.6 or later, another option might be to install from > the 64-bit/32-bit installer which is a good idea to do anyway. For pip > usage, a workaround would be to manually download distributions from > PyPI (or elsewhere) using a web browser and then use pip to install from > the downloaded file. The next version of pip is expected to have a > --no-check-certificate option that bypasses the certificate check at the > cost of reduced security. For the upcoming Python 2.7.9 release > (planned for early December), I intend to have the Pythons in the > python.org OS X installers use their own versions of OpenSSL and thus no > longer depend on the now-deprecated system OpenSSL. > > I just gave 2.7.9rc1 a go and seems like it is still linked to the same version of openssl?
Python 2.7.9rc1 (v2.7.9rc1:40eada278702, Nov 25 2014, 17:10:11) [GCC 4.2.1 (Apple Inc. build 5577)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> >>> import requests >>> requests.get("https://python.org") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/requests-2.4.3-py2.7.egg/requests/api.py", line 60, in get return request('get', url, **kwargs) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/requests-2.4.3-py2.7.egg/requests/api.py", line 49, in request return session.request(method=method, url=url, **kwargs) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/requests-2.4.3-py2.7.egg/requests/sessions.py", line 457, in request resp = self.send(prep, **send_kwargs) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/requests-2.4.3-py2.7.egg/requests/sessions.py", line 569, in send r = adapter.send(request, **kwargs) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/requests-2.4.3-py2.7.egg/requests/adapters.py", line 420, in send raise SSLError(e, request=request) requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) >>> >>> import ssl >>> ssl.OPENSSL_VERSION 'OpenSSL 0.9.7l 28 Sep 2006' > -- > Ned Deily, > n...@acm.org > > -- > https://mail.python.org/mailman/listinfo/python-list >
-- https://mail.python.org/mailman/listinfo/python-list