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

Reply via email to