A simple reproducer is: $ sudo apt-get install squid3 $ export HTTP_PROXY=http://localhost:3128 HTTPS_PROXY=https://localhost:3128 $ python3 -c "import requests; requests.get('https://api.github.com/events')"
This is a tough one to assign blame to but I actually think that Python 3.4.3 *fixed* a problem in this space, but that urllib3 --not requests!-- was buggy. What isn't obvious from the above is that upstream requests vendors urllib3, but in Ubuntu, we unbundle it. Further, your PPA includes not just a new requests but also a new urllib3. >From what I've read in the requests tracker, SNI support is actually the responsibility of urllib3. I've looked through the changelogs of both requests and urllib3 and haven't been able to match a bug fix with the relevant upstream releases in Ubuntu. Trusty has requests 2.2.1 and urllib3 1.7.1. But I still think ultimately it was a bug in urllib3 that got fixed in your PPA backport of 1.11 which fixes the above reproducer. So, I would propose that we backport both requests 2.7.0-3 and urllib3 1.11-1 (Wily versions both) to trusty-backports as a resolution of this problem. Would that work for you? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3.4 in Ubuntu. https://bugs.launchpad.net/bugs/1500768 Title: python3.4.3 SRU break requests Status in python3.4 package in Ubuntu: Confirmed Bug description: Sicne the upgade to python 3.4.3 on trusty, I'm getting this error when using a squid proxy: https://jenkins.qa.ubuntu.com/view/All/job/udtc-trusty-tests/1946/label=ps-trusty-desktop-amd64-1,type=large/testReport/tests.large.test_android/AndroidSDKTests/test_default_android_sdk_install/ The code is using python-requests, with verify=True for ssl connection (default). Some tests are testing that invalid certificates are rejected: https://github.com/ubuntu/ubuntu- make/blob/master/umake/network/download_center.py#L129 Rerunning the same code with previous trusty package (3.4.0~trusty1) doesn't show up this issue. It seems that SNI is broken for the trusty version of python3-requests with 3.4.3. (See the FAQ http://www .python-requests.org/en/latest/community/faq/ with "What are “hostname doesn’t match” errors?" and the stackoverflow question. I did run a test, grabbing requests 2.7 and backporting it to trusty (I needed to as well to take python3-urllib3 willy version). So, 3.4.3 has an incompatible change for existing projects and people with proxys are starting to see some breakage like in https://bugs.launchpad.net/ubuntu/+source/ubuntu-make/+bug/1499890. Can we get it fix somehow, reverting the incompatible change breaking SNI (I wonder if this is "Changed in version 3.4.3: This class now performs all the necessary certificate and hostname checks by default. To revert to the previous, unverified, behavior ssl._create_unverified_context() can be passed to the context parameter." in https://docs.python.org/3/library/http.client.html or something else) so that existing code can either get a new compatible python-requests or avoid incompatible changes in python 3.4.3? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1500768/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp