0.9.2-r2 causes issues, likely related to CN/subjectAltName matching for e.g glsamaker / cvetool, upgrading to 0.10.3 fixes this matter. @maintainers: can the newer version be stabilized? ## $ bin/cvetool assign 563220 CVE-2015-8011 CVE-2015-8012 Traceback (most recent call last): File "bin/cvetool", line 189, in <module> main() File "bin/cvetool", line 185, in main CVETool(auth, sys.argv[1], sys.argv[2:]) File "bin/cvetool", line 49, in __init__ self.assign(args[0], [self.cleanup_cve(cve) for cve in args[1:]]) File "bin/cvetool", line 94, in assign cve_ids = [self.get_internal_cve_id(cve) for cve in cves] File "bin/cvetool", line 94, in <listcomp> cve_ids = [self.get_internal_cve_id(cve) for cve in cves] File "bin/cvetool", line 145, in get_internal_cve_id return self.json_request('/cve/info/' + cve + '.json')['id'] File "bin/cvetool", line 148, in json_request return json.loads(self.request(uri, method)) File "bin/cvetool", line 163, in request response, content = client.request(full_uri, method, headers = { 'Authorization': 'Basic ' + self.auth }) File "/usr/lib64/python3.4/site-packages/httplib2/__init__.py", line 1314, in request (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey) File "/usr/lib64/python3.4/site-packages/httplib2/__init__.py", line 1064, in _request (response, content) = self._conn_request(conn, request_uri, method, body, headers) File "/usr/lib64/python3.4/site-packages/httplib2/__init__.py", line 987, in _conn_request conn.connect() File "/usr/lib64/python3.4/http/client.py", line 1287, in connect server_hostname=server_hostname) File "/usr/lib64/python3.4/ssl.py", line 362, in wrap_socket _context=self) File "/usr/lib64/python3.4/ssl.py", line 580, in __init__ self.do_handshake() File "/usr/lib64/python3.4/ssl.py", line 807, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)
To be precise: dev-python/httplib2-0.9.2-r2 bundles an own certificate store which doesn't support Let's Encrypt yet. 0.10.3 contains https://github.com/httplib2/httplib2/commit/8dd5057d9d8aeccda08f18a63a8b6caec0db2f8a which adds Let's Encrypt support. However, we will come up with an additional bug requesting to patch httplib2 to use system's certificate store per default (something like https://sources.debian.net/src/python-httplib2/0.9.2%2Bdfsg-1/debian/patches/use_system_cacerts.patch/).
dev-python/httplib2-0.10.3-r1 is now in repository which makes use of the system's certificate store. We will start stabilization in a few days.
@ Arches, please test and mark stable: =dev-python/httplib2-0.10.3-r1
Stable on amd64.
ia64 stable
x86 and arm stabilized
Stable on alpha.
ppc64 stable
ppc stable
Builds fine on sparc, but how to test?
(In reply to Rolf Eike Beer from comment #10) > Builds fine on sparc, but how to test? The included tests require network access, and fail anyway due to the server returning unexpected response codes. If you want, you could remove the test restriction, disable network-sandbox, and run the tests. I would expect a result like this: > Ran 125 tests in 18.636s > > FAILED (failures=44, errors=12)
I merged this into the system and ran the testsuite by hand. Results were similar to the given numbers: python2: FAILED (failures=45, errors=13) python3: FAILED (failures=44, errors=11)
sparc stable (thanks to Rolf Eike Beer) Last arch. Closing.