[Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

[Ned Deily]

On Jan 14, 2018, at 08:39, Christian Heimes <christian at 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.

> 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.

--
  Ned Deily
  nad at python.org -- []