Heads up to anyone running pypiserver, this breaks the default redirection from pypiserver to PyPI. There's an open issue[1] to fix it. In the meantime, you can use the pypiserver option `--fallback-url https://pypi.python.org/simple/` to work around it.

--nate

[1] https://github.com/pypiserver/pypiserver/issues/179

On Thu, Oct 26, 2017 at 11:11 AM, Donald Stufft <donald@stufft.io> wrote:
Historically PyPI was only available over either HTTP or unvalidated HTTPS, and over time we’ve been pushing more and more traffic onto HTTPS. In Warehouse the decision was made to *not* redirect “API” URLs from HTTP to HTTPS, but to rather return an error accessing them from HTTP. This is because while logged in views have HSTS to ensure HTTPS in the browser (and with humans manually entering them into the URL bar regularly they are more error prone) APIs which are typically accessed by automated clients with an URL configured or hardcoded typically do not respect HSTS, so if you had a script that did ``curl http://pypi.python.org/simple/``, it would silently get redirects to https and appear to “work”, but you wouldn’t get any of the security properties of TLS because an attacker would just intercept the request prior to the redirect happening.

Today I’ve backported this changed to the current production deployment of PyPI, which means that you can no longer access /simple/ and /packages/ over HTTP and you will have to directly go to HTTPS. For most people this should have no effect, because most tooling should be defaulting to HTTPS anyways, however if you’re using a significantly old version of tooling, it may still be defaulting to the HTTP url and will now stop functioning.

The recommended remediation is to upgrade your tooling to versions that support verified TLS connections and which default to the proper HTTPS URLs.

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig