Sun, 17 Jul 2016 11:28:01 -0700 tests: update test certificate generation instructions
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 17 Jul 2016 11:28:01 -0700] rev 29579
tests: update test certificate generation instructions Suggestions from Anton Shestakov and Julien Cristau to use -subj and faketime, respectively.
Sun, 17 Jul 2016 11:03:08 -0700 sslutil: move comment about protocol constants
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 17 Jul 2016 11:03:08 -0700] rev 29578
sslutil: move comment about protocol constants protocolsettings() is the appropriate place for this comment.
Sun, 17 Jul 2016 10:59:32 -0700 sslutil: support defining cipher list
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 17 Jul 2016 10:59:32 -0700] rev 29577
sslutil: support defining cipher list Python 2.7 supports specifying a custom cipher list to TLS sockets. Advanced users may wish to specify a custom cipher list to increase security. Or in some cases they may wish to prefer weaker ciphers in order to increase performance (e.g. when doing stream clones of very large repositories). This patch introduces a [hostsecurity] config option for defining the cipher list. The help documentation states that it is for advanced users only. Honestly, I'm a bit on the fence about providing this because it is a footgun and can be used to decrease security. However, there are legitimate use cases for it, so I think support should be provided.
Sun, 17 Jul 2016 10:50:51 -0700 hghave: add test for Python 2.7+
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 17 Jul 2016 10:50:51 -0700] rev 29576
hghave: add test for Python 2.7+ Setting ciphers in the ssl module requires Python 2.7. Surprisingly, we didn't have a test for running on Python 2.7.
Sat, 16 Jul 2016 15:06:19 +0800 spartan: make different blocks of annotated lines have different colors
Anton Shestakov <av6@dwimlabs.net> [Sat, 16 Jul 2016 15:06:19 +0800] rev 29575
spartan: make different blocks of annotated lines have different colors
Sat, 16 Jul 2016 15:06:04 +0800 monoblue: make different blocks of annotated lines have different colors
Anton Shestakov <av6@dwimlabs.net> [Sat, 16 Jul 2016 15:06:04 +0800] rev 29574
monoblue: make different blocks of annotated lines have different colors
Sat, 16 Jul 2016 15:00:36 +0800 gitweb: make different blocks of annotated lines have different colors
Anton Shestakov <av6@dwimlabs.net> [Sat, 16 Jul 2016 15:00:36 +0800] rev 29573
gitweb: make different blocks of annotated lines have different colors
Sat, 16 Jul 2016 14:49:07 +0800 paper: make different blocks of annotated lines have different colors
Anton Shestakov <av6@dwimlabs.net> [Sat, 16 Jul 2016 14:49:07 +0800] rev 29572
paper: make different blocks of annotated lines have different colors
Fri, 20 May 2016 09:47:35 +0900 tests: check importing modules in perf.py for historical portability
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 20 May 2016 09:47:35 +0900] rev 29571
tests: check importing modules in perf.py for historical portability To check importing modules in perf.py for historical portability, this patch lists up files by "hg files" both for "1.2" and tip, and builds up "module whitelist" check from those files. This patch uses "1.2" as earlier side version of "module whitelist", because "mercurial.error" module is a blocker for loading perf.py with Mercurial earlier than 1.2, and just importing "mercurial.error" separately isn't enough.
Fri, 20 May 2016 09:47:35 +0900 tests: introduce check-perf-code.py to add extra checks on perf.py
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 20 May 2016 09:47:35 +0900] rev 29570
tests: introduce check-perf-code.py to add extra checks on perf.py This patch introduces tests/check-perf-code.py as a preparation for adding extra checks on contrib/perf.py in subsequent patches (mainly, for historical portability). At this change, check-perf-code.py doesn't add any extra check, and is equal to check-code.py. This makes subsequent patch focus only on adding an extra check on perf.py check-perf-code.py. check-perf-code.py adds extra checks on perf.py by wrapping contrib/check-code.py, because "filtering" by check-code.py (e.g. normalize characters in string literal or comment line) is useful to simplify regexp for check, and avoid false positive matching.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip