touch-packages team mailing list archive

[Didier Roche <didrocks@xxxxxxxxxx>]

Ok, let me clarify some points here.

First, I pointed that change as it's the closest thing that changed in python 3.4.3 which can have an impact on SNI, it may be something different which broke requests.
The invalid certificate tests is a test that is passing (this was to underline that I already had verfiy=true and checked that the SSL certificate check was done, as I was aware about the non check of it in python)

So, what is broken? I think the target is the SNI support with older request
1. Setup
- Install ubuntu-make from ubuntu-desktop/ubuntu-make ppa
- Have a proxy (squid.internal) for instance, filtering your network
- Export HTTPS_PROXY to point to your squid internal proxy

2. With python 3.4.0:
- Run "umake android" -> android-studio resolve, show the license page and install

3. With python 3.4.3 (current 14.04):
-  Run "umake android" -> you will get the hostname 'squid.internal' doesn't match either of '*.google.com', '*.android.com', '*.appengine.google.com', '*.cloud.google.com', '*.google-analytics.com', '*.google.ca', <…>' message (content depending on the allowed site from your proxy).

4. With python 3.4.3 + requests 2.7 backported in my ppa (didrocks/ppa):
- Run "umake android" -> android-studio resolve, show the license page and install

As you can see, Ubuntu Make code didn't change at all in any of those
tests, I think requests post 2.2.1 has something that made SNI work with
python 3.4.3.

As long as you have the right proxy config, I think this should simply fail:
import requests
requests.get('https://api.github.com/events')

-- 
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