On 2018-01-14 16:54, Ned Deily wrote: > On Jan 14, 2018, at 08:39, Christian Heimes <christ...@python.org> wrote: >> On 2018-01-14 09:24, Matt Billenstein wrote: >>> Correct me if I'm wrong, but Python3 on osx bundles openssl since Apple has >>> deprecated (and no longer ships the header files for) the version shipped >>> with >>> recent versions of osx. >>> >>> Perhaps this is an option to support the various flavors of Linux as well? >> >> AFAK Apple has decided to compile and statically link CPython's ssl with >> an ancient, customized LibreSSL version. Cory posted [1] a couple of >> months ago > > I think you're conflating some things here. Apple has not yet shipped a > version of Python 3 with macOS so the fact that Apple now links their > version of Python2.7 with a "private" copy of LibreSSL is irrelevant. > (It's private in the sense that they don't ship the header files for it; > the shared libs are there just for the use of the open source products > they ship with macOS that don't yet use the macOS native crypto APIs, > products like Python and Perl.) > > What Matt is likely thinking of is the Python 3 versions provided by the > python.org macOS binary installers where we do build and link with our > own 1.0.2 (and soon 1.1.0 for 3.7) versions of OpenSSL. Currently, > the OpenSSL (and several other third-party libs such as libxz which > is not shipped by Apple) are built as part of the installer build > script in the Mac section of the source repo. I would like to > refactor and generalize that so those third-party libs > could optionally be used for non-installer builds as well. But, in > any case, we don't have much choice for the installer builds until > such time as cPython has support for the Apple-provided crypto APIs.
Yeah, that sounds useful for macOS and Windows development. Back when I was doing more Windows stuff, I used our buildbot scripts to provide local builds of dependencies such as expat and OpenSSL. >> I'm not going to add OpenSSL sources or builds to CPython. We just got >> rid of copies of libffi and other 3rd party dependencies. Crypto and TLS >> libraries are much, MUCH more complicated to handle than libffi. It's a >> constant moving targets of attacks. Vendors and distributions also have >> different opinions about trust store and policies. >> >> Let's keep build dependencies a downstream and vendor problem. > > That's not always an option, unfortunately. For Python.org macOS and Windows installers, I'm considering us as our own downstream vendors. I should rather say "Steve and you" instead of us. You are both doing the heavy lifting. Thanks for you hard work. :) Christian _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
