Fri, 01 Jul 2016 15:12:33 -0500 Added signature for changeset 26a5d605b868 stable
Matt Mackall <mpm@selenic.com> [Fri, 01 Jul 2016 15:12:33 -0500] rev 29454
Added signature for changeset 26a5d605b868
Fri, 01 Jul 2016 15:12:32 -0500 Added tag 3.8.4 for changeset 26a5d605b868 stable
Matt Mackall <mpm@selenic.com> [Fri, 01 Jul 2016 15:12:32 -0500] rev 29453
Added tag 3.8.4 for changeset 26a5d605b868
Sun, 26 Jun 2016 19:34:48 -0700 sslutil: synchronize hostname matching logic with CPython stable 3.8.4
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 26 Jun 2016 19:34:48 -0700] rev 29452
sslutil: synchronize hostname matching logic with CPython sslutil contains its own hostname matching logic. CPython has code for the same intent. However, it is only available to Python 2.7.9+ (or distributions that have backported 2.7.9's ssl module improvements). This patch effectively imports CPython's hostname matching code from its ssl.py into sslutil.py. The hostname matching code itself is pretty similar. However, the DNS name matching code is much more robust and spec conformant. As the test changes show, this changes some behavior around wildcard handling and IDNA matching. The new behavior allows wildcards in the middle of words (e.g. 'f*.com' matches 'foo.com') This is spec compliant according to RFC 6125 Section 6.5.3 item 3. There is one test where the matcher is more strict. Before, '*.a.com' matched '.a.com'. Now it doesn't match. Strictly speaking this is a security vulnerability.
Sun, 26 Jun 2016 19:16:54 -0700 tests: import CPython's hostname matching tests stable
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 26 Jun 2016 19:16:54 -0700] rev 29451
tests: import CPython's hostname matching tests CPython has a more comprehensive test suite for it's built-in hostname matching functionality. This patch adds its tests so we can improve our hostname matching functionality. Many of the tests have different results from CPython. These will be addressed in a subsequent commit.
Fri, 01 Jul 2016 07:41:37 -0300 i18n-pt_BR: synchronized with dd9175ca81dc stable
Wagner Bruna <wbruna@yahoo.com> [Fri, 01 Jul 2016 07:41:37 -0300] rev 29450
i18n-pt_BR: synchronized with dd9175ca81dc
Wed, 29 Jun 2016 19:43:27 -0700 sslutil: emit warning when no CA certificates loaded
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 29 Jun 2016 19:43:27 -0700] rev 29449
sslutil: emit warning when no CA certificates loaded If no CA certificates are loaded, that is almost certainly a/the reason certificate verification fails when connecting to a server. The modern ssl module in Python 2.7.9+ provides an API to access the list of loaded CA certificates. This patch emits a warning on modern Python when certificate verification fails and there are no loaded CA certificates. There is no way to detect the number of loaded CA certificates unless the modern ssl module is present. Hence the differences in test output depending on whether modern ssl is available. It's worth noting that a test which specifies a CA file still renders this warning. That is because the certificate it is loading is a x509 client certificate and not a CA certificate. This test could be updated if anyone is so inclined.
Wed, 29 Jun 2016 19:49:39 -0700 tests: test case where default ca certs not available
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 29 Jun 2016 19:49:39 -0700] rev 29448
tests: test case where default ca certs not available I'm not a fan of TLS tests not testing both branches of a possible configuration. While we have test coverage of the inability to validate a cert later in this file, I insist that we add this branch so our testing of security code is extra comprehensive.
Wed, 29 Jun 2016 19:38:24 -0700 sslutil: don't load default certificates when they aren't relevant
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 29 Jun 2016 19:38:24 -0700] rev 29447
sslutil: don't load default certificates when they aren't relevant Before, we would call SSLContext.load_default_certs() when certificate verification wasn't being used. Since SSLContext.verify_mode == ssl.CERT_NONE, this would ideally no-op. However, there is a slim chance the loading of system certs could cause a failure. Furthermore, this behavior interfered with a future patch that aims to provide a more helpful error message when we're unable to load CAs. The lack of test fallout is hopefully a sign that our security code and tests are in a relatively good state.
Wed, 29 Jun 2016 19:37:38 -0700 sslutil: display a better error message when CA file loading fails
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 29 Jun 2016 19:37:38 -0700] rev 29446
sslutil: display a better error message when CA file loading fails Before, sslcontext.load_verify_locations() would raise a ssl.SSLError which would be caught further up the stack and converted to a urlerror. By that time, we lost track of what actually errored. Trapping the error here gives users a slightly more actionable error message. The behavior between Python <2.7.9 and Python 2.7.9+ differs. This is because our fake SSLContext class installed on <2.7.9 doesn't actually do anything during load_verify_locations: it defers actions until wrap_socket() time. Unfortunately, a number of errors can occur at wrap_socket() time and we're unable to ascertain what the root cause is. But that shouldn't stop us from providing better error messages to people running a modern and secure Python version.
Wed, 29 Jun 2016 18:15:28 -0700 tests: add test for empty CA certs file
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 29 Jun 2016 18:15:28 -0700] rev 29445
tests: add test for empty CA certs file smf reported that an environment with no loaded CA certs resulted in a weird error. I'd like to detect this a bit better so we can display an actionable error message. The actual error being globbed over in this patch is "unknown error" with a ssl.c line number. That isn't useful at all.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip