touch-packages team mailing list archive

[Barry Warsaw <1500768@xxxxxxxxxxxxxxxxxx>]

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