Wagner Bruna <wbruna@softwareexpress.com.br> [Fri, 01 Oct 2010 11:15:10 -0300] rev 12600
merge with i18n stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 01 Oct 2010 17:24:18 +0900] rev 12599
i18n-ja: synchronized with e356c5c21b15
Matt Mackall <mpm@selenic.com> [Thu, 30 Sep 2010 19:10:19 -0500] rev 12598
merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 30 Sep 2010 19:09:58 -0500] rev 12597
merge with i18n
Wagner Bruna <wbruna@softwareexpress.com.br> [Thu, 30 Sep 2010 14:07:57 -0300] rev 12596
i18n-pt_BR: synchronized with 552e0cfbddbd
Mads Kiilerich <mads@kiilerich.com> [Fri, 01 Oct 2010 00:54:03 +0200] rev 12595
merge with stable
Mads Kiilerich <mads@kiilerich.com> [Fri, 01 Oct 2010 00:48:51 +0200] rev 12594
test-doctest: test the modules that contains doctests
Mads Kiilerich <mads@kiilerich.com> [Fri, 01 Oct 2010 00:48:50 +0200] rev 12593
doc: clarify that https cert verification requires web.cacerts
Mads Kiilerich <mads@kiilerich.com> [Fri, 01 Oct 2010 00:46:59 +0200] rev 12592
url: verify correctness of https server certificates (issue2407)
Pythons SSL module verifies that certificates received for HTTPS are valid
according to the specified cacerts, but it doesn't verify that the certificate
is for the host we connect to.
We now explicitly verify that the commonName in the received certificate
matches the requested hostname and is valid for the time being.
This is a minimal patch where we try to fail to the safe side, but we do still
rely on Python's SSL functionality and do not try to implement the standards
fully and correctly. CRLs and subjectAltName are not handled and proxies
haven't been considered.
This change might break connections to some sites if cacerts is specified and
the certificates (by our definition) isn't correct. The workaround is to
disable cacerts which in most cases isn't much worse than it was before with
cacerts.
Erik Zielke <ez@aragost.com> [Thu, 30 Sep 2010 13:38:21 +0200] rev 12591
test-subrepo-recursion: remove empty defaults section