Sun, 31 May 2020 00:30:49 +0200 config: remove unused hostsecurity.disabletls10warning config
Manuel Jacob <me@manueljacob.de> [Sun, 31 May 2020 00:30:49 +0200] rev 44896
config: remove unused hostsecurity.disabletls10warning config
Sun, 31 May 2020 22:15:35 +0200 sslutil: remove dead code (that downgraded default minimum TLS version)
Manuel Jacob <me@manueljacob.de> [Sun, 31 May 2020 22:15:35 +0200] rev 44895
sslutil: remove dead code (that downgraded default minimum TLS version) We ensure in setup.py that TLS 1.1 or TLS 1.2 is present.
Fri, 29 May 2020 22:47:58 +0200 sslutil: remove comment referring to unsupported legacy stacks
Manuel Jacob <me@manueljacob.de> [Fri, 29 May 2020 22:47:58 +0200] rev 44894
sslutil: remove comment referring to unsupported legacy stacks
Sat, 30 May 2020 23:42:19 +0200 setup: require that Python has TLS 1.1 or TLS 1.2
Manuel Jacob <me@manueljacob.de> [Sat, 30 May 2020 23:42:19 +0200] rev 44893
setup: require that Python has TLS 1.1 or TLS 1.2 This ensures that Mercurial never downgrades the minimum TLS version from TLS 1.1+ to TLS 1.0+ and enables us to remove that compatibility code. It is reasonable to expect that distributions having Python 2.7.9+ or having backported modern features to the ssl module (which we require) have a OpenSSL version supporting TLS 1.1 or TLS 1.2, as this is the main reason why distributions would want to backport these features. TLS 1.1 and TLS 1.2 are often either both enabled or both not enabled. However, both can be disabled independently, at least on current Python / OpenSSL versions. For the record, I contacted the CPython developers to remark that unconditionally defining ssl.PROTOCOL_TLSv1_1 / ssl.PROTOCOL_TLSv1_2 is problematic: https://github.com/python/cpython/commit/6e8cda91d92da72800d891b2fc2073ecbc134d98#r39569316
Sun, 31 May 2020 12:07:17 +0200 sslutil: check for OpenSSL without TLS 1.0 support in one case
Manuel Jacob <me@manueljacob.de> [Sun, 31 May 2020 12:07:17 +0200] rev 44892
sslutil: check for OpenSSL without TLS 1.0 support in one case It can only happen if supportedprotocols gets fixed to contain only correct items (see the FIXME above in the file).
Sun, 31 May 2020 11:10:21 +0200 sslutil: don't set minimum TLS version to 1.0 if 1.2 but not 1.1 is available
Manuel Jacob <me@manueljacob.de> [Sun, 31 May 2020 11:10:21 +0200] rev 44891
sslutil: don't set minimum TLS version to 1.0 if 1.2 but not 1.1 is available This case isn't very likely, but possible, especially if supportedprotocols gets fixed to contain only correct items (see the FIXME above in the file).
Sun, 31 May 2020 11:41:03 +0200 sslutil: add FIXME about supportedprotocols possibly containing too many items
Manuel Jacob <me@manueljacob.de> [Sun, 31 May 2020 11:41:03 +0200] rev 44890
sslutil: add FIXME about supportedprotocols possibly containing too many items
Sun, 31 May 2020 10:47:38 +0200 sslutil: fix names of variables containing minimum protocol strings
Manuel Jacob <me@manueljacob.de> [Sun, 31 May 2020 10:47:38 +0200] rev 44889
sslutil: fix names of variables containing minimum protocol strings When working in this module, I found it very confusing that "protocol" as a variable name could mean either "minimum protocol string" or an exact version (as a string or ssl.PROTOCOL_* value). This patch prefixes variables of the former type with "minimum".
Sun, 31 May 2020 09:55:45 +0200 sslutil: stop returning argument as third return value of protocolsettings()
Manuel Jacob <me@manueljacob.de> [Sun, 31 May 2020 09:55:45 +0200] rev 44888
sslutil: stop returning argument as third return value of protocolsettings() The third return value was always the same as the argument.
Sat, 30 May 2020 23:18:57 +0200 relnotes: note that we now require modern SSL/TLS features in Python
Manuel Jacob <me@manueljacob.de> [Sat, 30 May 2020 23:18:57 +0200] rev 44887
relnotes: note that we now require modern SSL/TLS features in Python
Sat, 30 May 2020 19:04:53 +0200 tests: stop checking for optional, now impossible output
Manuel Jacob <me@manueljacob.de> [Sat, 30 May 2020 19:04:53 +0200] rev 44886
tests: stop checking for optional, now impossible output In 7dd63a8cb1ee, the code that could output that line was removed.
Sat, 30 May 2020 10:19:53 -0400 rust: remove one more occurrence of re2
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sat, 30 May 2020 10:19:53 -0400] rev 44885
rust: remove one more occurrence of re2 Differential Revision: https://phab.mercurial-scm.org/D8601
Tue, 26 May 2020 07:03:11 -0400 scmutil: clarify getuipathfn comment
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Tue, 26 May 2020 07:03:11 -0400] rev 44884
scmutil: clarify getuipathfn comment Differential Revision: https://phab.mercurial-scm.org/D8600
Thu, 28 May 2020 09:51:13 -0400 githelp: add some minimal help for pickaxe functionality
Augie Fackler <augie@google.com> [Thu, 28 May 2020 09:51:13 -0400] rev 44883
githelp: add some minimal help for pickaxe functionality Due to a conversation in work chat, I realized this is actually pretty well-hidden in Mercurial. Differential Revision: https://phab.mercurial-scm.org/D8590
Fri, 17 Apr 2020 10:41:05 +0200 rust: remove duplicate import
Raphaël Gomès <rgomes@octobus.net> [Fri, 17 Apr 2020 10:41:05 +0200] rev 44882
rust: remove duplicate import Differential Revision: https://phab.mercurial-scm.org/D8456
Sat, 30 May 2020 05:27:53 +0200 tests: remove "sslcontext" check
Manuel Jacob <me@manueljacob.de> [Sat, 30 May 2020 05:27:53 +0200] rev 44881
tests: remove "sslcontext" check Now that we require the presence of ssl.SSLContext in setup.py, the check would always return `True`.
(0) -30000 -10000 -3000 -1000 -300 -100 -16 +16 +100 +300 +1000 +3000 tip