In Modules/_ssl.c, I see:
---
#if OPENSSL_VERSION_NUMBER < 0x10001000L                   
    dps = X509_get_ext_d2i(certificate, NID_crl_distribution_points,
                           NULL, NULL);
#else                            
    /* Calls x509v3_cache_extensions and sets up crldp */ 
    X509_check_ca(certificate);                     
    dps = certificate->crldp;
#endif   
---

But later X509_check_ca() is used without checking for OpenSSL versions: in cert_store_stats() and get_ca_certs().

As as result, the _ssl cannot be compiled on our FreeBSD 6.4 buildbot anymore.

http://buildbot.python.org/all/builders/x86%20FreeBSD%206.4%203.x/builds/4590/steps/test/logs/stdio

building '_ssl' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c -o build/temp.freebsd-6.4-RELEASE-i386-3.4-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.o
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c: In function `_get_peer_alt_names':
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c:818: warning: passing arg 2 of `ASN1_item_d2i' from incompatible pointer type
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c:823: warning: passing arg 2 of pointer to function from incompatible pointer type
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c: In function `PySSL_cipher':
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c:1374: warning: passing arg 1 of `SSL_CIPHER_get_name' discards qualifiers from pointer target type
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c:1384: warning: passing arg 1 of `SSL_CIPHER_get_version' discards qualifiers from pointer target type
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c:1394: warning: passing arg 1 of `SSL_CIPHER_get_bits' discards qualifiers from pointer target type
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c: In function `cert_store_stats':
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.c:3045: warning: implicit declaration of function `X509_check_ca'
gcc -pthread -shared build/temp.freebsd-6.4-RELEASE-i386-3.4-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.freebsd-6.4-RELEASE-i386-3.4-pydebug/_ssl.so
*** WARNING: renaming "_ssl" since importing it failed: build/lib.freebsd-6.4-RELEASE-i386-3.4-pydebug/_ssl.so: Undefined symbol "X509_check_ca"
building '_multiprocessing' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -IModules/_multiprocessing -I./Include -I. -IInclude -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_multiprocessing/multiprocessing.c -o build/temp.freebsd-6.4-RELEASE-i386-3.4-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_multiprocessing/multiprocessing.o
gcc -pthread -shared build/temp.freebsd-6.4-RELEASE-i386-3.4-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_multiprocessing/multiprocessing.o -L/usr/local/lib -o build/lib.freebsd-6.4-RELEASE-i386-3.4-pydebug/_multiprocessing.so
*** WARNING: renaming "_multiprocessing" since importing it failed: build/lib.freebsd-6.4-RELEASE-i386-3.4-pydebug/_multiprocessing.so: Undefined symbol "_PyMp_sem_unlink"

Python build finished successfully!
The necessary bits to build these optional modules were not found:
spwd                                                           
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_multiprocessing      _ssl

It looks like FreeBSD 6.4 includes OpenSSL 0.9.7, whereas X509_check_ca() requires OpenSSL 0.9.8 or newer.

FreeBSD 6.4 is EOL though, for quite some time already:

http://lists.freebsd.org/pipermail/freebsd-announce/2010-September/001344.html


Maybe we should ask the buildbot owner to upgrade to something
newer.

Both of my FreeBSD buildbots are quite ancient (particularly so with FreeBSD/6.4), and mostly still exist because of lack of pressure to change them, and at least for a while having an older, legacy FreeBSD buildbot was of some use.

I have no plans on upgrading though, but always assumed I'd just retire them if they became more hassle than they were worth.  Certainly I wouldn't worry too much about supporting 6.4 in ongoing development, so the writing might be on the wall now for that buildbot.

-- David

If we drop support of FreeBSD older than 8.x for example, we should
make it official. Mention it at least in the What's New in Python 3.5
and/or the PEP 11. What do you think?

I suppose it depends on what the current policy (if any) is.  Not sure how far back we would officially claim to support even today.  We have a 6.4 buildbot due to history, but it's never made the stable list, and is probably in a failing state as much or more as passing.  Certainly in the FreeBSD world, I expect the overlap between anyone still using FreeBSD 6 and yet wanting to use the latest and greatest python is awfully small.

With respect to PEP 11 though, noting that we no longer support OpenSSL < 0.9.8 as of some release seems a reasonable point.  Not sure I'd specifically target FreeBSD 6.4 as much as OpenSSL.

Starting with 2.7.9, this affects the 2.7 branch as well.

Please note that it's not only out-of-maintenance FreeBSD versions that are affected, but also a current version of Solaris, namely Solaris 10. The end of "Premier" support for Solaris 10 is January 2018 and the end of "Extended" support for Solaris 10 is January 2021, according to http://www.oracle.com/us/support/library/lifetime-support-hardware-301321.pdf

Solaris 10 has OpenSSL 0.9.7 and all security fixes are back-ported to it, more at https://blogs.oracle.com/darren/entry/openssl_versions_in_solaris

0.9.7 is truly ancient. I'd rather not add more conditional code and let people maintain their fork of Python if they already maintain a fork of OpenSSL.

For the record, this is an issue in Red Hat Enterprise Linux 4 too. For RHEL 4, "Extended" support ends on March 31, 2017, according to https://access.redhat.com/support/policy/updates/errata

For ancient OSes such as RHEL 4, I would suggest people request backports from the OS vendor if desired.