Looks like they ship a shared lib on osx which is different from how they
handle 2.7:
mattb@mattb-mbp2:/Library/Frameworks/Python.framework/Versions $ find . -name
'*ssl*.so' | xargs otool -L
./2.7/lib/python2.7/lib-dynload/_ssl.so:
/usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current
version 0.9.8)
/usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current
version 0.9.8)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.2.0)
./3.6/lib/python3.6/lib-dynload/_ssl.cpython-36m-darwin.so:
/Library/Frameworks/Python.framework/Versions/3.6/lib/libssl.1.0.0.dylib
(compatibility version 1.0.0, current version 1.0.0)
/Library/Frameworks/Python.framework/Versions/3.6/lib/libcrypto.1.0.0.dylib
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.2.0)
I thought I saw some talk of enhancements on python-dev in ssl in python that
were only being done in python3 which is maybe why they do it this way.
m
On Thu, Jan 04, 2018 at 06:50:39AM +0200, Matti Picus wrote:
> On 1/4/2018 3:15 AM, Nathaniel Smith wrote:
>
> >On Wed, Jan 3, 2018 at 3:51 PM, Alex Gaynor <alex.gay...@gmail.com> wrote:
> >>If PyPy releases include a copy of OpenSSL (or LibreSSL) then we need to be
> >>in the business of issuing new releases whenever upstream has a security
> >>release, we can't be shipping people OpenSSLs with known security issues.
> >>
> >>Of LibreSSL and OpenSSL, I'd choose to ship OpenSSL -- I've found LibreSSL
> >>fairly frustrating to work with and OpenSSL upstream is considerably cleaned
> >>up in past years.
> >None of Linux, Windows, or MacOS provide reasonable pre-existing
> >OpenSSL installs you can use. So it seems to me that if PyPy's going
> >to ship any binaries at all and take that seriously, then it's going
> >to have to ship OpenSSL (or LibreSSL), and do whatever security
> >updates you all decide make sense.
> >
> >It's also probably not worth spending a lot of time trying to figure
> >out how to avoid doing security updates for pypy2 on MacOS, if you're
> >still going to have to do them for other binaries on other platforms.
> >
> >-n
> >
> Let's leave libffi out of the discussion, I assume there is no
> objection to statically linking to it.
>
> As for OpenSSL/LibreSSL the situation is not straight-forward. Here
> is my assessment, please correct me if I am wrong.
>
> In windows, both PyPy and CPython statically link to OpenSSL
>
> In linux, PyPy and CPython use the platform OpenSSL.
>
> On macosx, _ssl cffi (as of the first release v5.10) uses a
> statically-linked LibreSSL with a patch for python3, and on python2
> AFAICT both CPython and PyPy use a platform library, not clear to me
> which one.
>
> What does CPython do for macosx python3?
>
> Matti
--
Matt Billenstein
m...@vazor.com
http://www.vazor.com/
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
