As noted in https://github.com/travis-ci/travis-ci/issues/9069, Travis CI's Ubuntu 14.04 environment includes an OpenSSL that's too old to meet Python 3.7's security requirements.

According to https://github.com/travis-ci/travis-ci/issues/9069#issuecomment-395471575, setting "dist: xenial" instead (giving Ubuntu 16.04) provides a testing environment with a new enough OpenSSL for 3.7 to work.

I'm thinking it would make the most sense as a subsection under https://docs.python.org/dev/whatsnew/3.7.html#platform-support-removals

(https://docs.python.org/dev/whatsnew/3.7.html#ssl does mention this information in a note, but that uses the OpenSSL version numbers directly, which folks aren't necessarily going to know to go to distrowatch to check which Travis environment they need to select: https://distrowatch.com/table.php?distribution=Ubuntu )

> According to https://github.com/travis-ci/travis-ci/issues/9069#issuecomment-395471575, setting "dist: xenial" instead (giving Ubuntu 16.04) provides a testing environment with a new enough OpenSSL for 3.7 to work.

No, this doesn't work either. The xenial environment is an experimental feature and doesn't work at all reliably. At the time of this writing setting "dist: xenial" actually puts you into Trusty.

Currently the viable ways of making it work on Travis are to either run a custom docker image (which requires you to opt out of their containerized builds and thus makes everything slower), or to build OpenSSL yourself (and making the latter work correctly is a far from straightforward process).

OK, given the above feedback, the PR I've created isn't right yet, but it at least shows where any information that we can provide on this point will end up.

Also adding Łukasz to the nosy list, since it was his comment from a few weeks ago on the Travis CI ticket that prompted my "dist: xenial" suggestion.

I've updated the PR to match my current understanding of the situation with Debian 8 and Ubuntu 14.04.

Anthony Sottile has pointed out to me that I'm wrong about the xenial thing, and that actually it does work it's just that you need to get multiple things right in order for it to do so. https://github.com/deadsnakes/travis-ci-python3.7-example is a good example of making it work.

Why should we mention Travis-CI at all? It's Travis-CI's job to document the binaries and runtimes they provide on each of their build environments.

Given the update in https://github.com/deadsnakes/travis-ci-python3.7-example#update-2018-07-03, I've simplified the PR to remove any references to Travis CI, and instead just mention the code names for the relevant Debian and Ubuntu releases.

I've also kept the pointer to our CI config for building your own Python against OpenSSL 1.1.0, regardless of the host OS state.

New changeset 5fe7c98a54d127759cfce323fab831008c945964 by Nick Coghlan in branch 'master':
bpo-34009: Expand on platform support changes (GH-8022)
https://github.com/python/cpython/commit/5fe7c98a54d127759cfce323fab831008c945964

New changeset 5cca6f9fbead1fae27c37204f345a9465cc88959 by Miss Islington (bot) in branch '3.7':
bpo-34009: Expand on platform support changes (GH-8022)
https://github.com/python/cpython/commit/5cca6f9fbead1fae27c37204f345a9465cc88959

Merged to master and 3.7 - any further wording tweaks can be handled as a trivial docs-only PR, without needing additional tracker issues.