Mon, 30 May 2016 11:19:43 -0700 sslutil: remove "strict" argument from validatesocket()
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 30 May 2016 11:19:43 -0700] rev 29286
sslutil: remove "strict" argument from validatesocket() It was only used by mail.py as part of processing smtp.verifycert, which was just removed.
Sat, 04 Jun 2016 11:13:28 -0700 mail: unsupport smtp.verifycert (BC)
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 04 Jun 2016 11:13:28 -0700] rev 29285
mail: unsupport smtp.verifycert (BC) smtp.verifycert was accidentally broken by cca59ef27e60. And, I believe the "loose" value has been broken for longer than that. The current code refuses to talk to a remote server unless the CA is trusted or the fingerprint is validated. In other words, we lost the ability for smtp.verifycert to lower/disable security. There are special considerations for smtp.verifycert in sslutil.validatesocket() (the "strict" argument). This violates the direction sslutil is evolving towards, which has all security options determined at wrapsocket() time and a unified code path and configs for determining security options. Since smtp.verifycert is broken and since we'll soon have new security defaults and new mechanisms for controlling host security, this patch formally deprecates smtp.verifycert. With this patch, the socket security code in mail.py now effectively mirrors code in url.py and other places we're doing socket security. For the record, removing smtp.verifycert because it was accidentally broken is a poor excuse to remove it. However, I would have done this anyway because smtp.verifycert is a one-off likely used by few people (users of the patchbomb extension) and I don't think the existence of this seldom-used one-off in security code can be justified, especially when you consider that better mechanisms are right around the corner.
Tue, 05 Apr 2016 07:30:01 +0200 update: fix bare --clean to work on new branch (issue5003) (BC)
liscju <piotr.listkiewicz@gmail.com> [Tue, 05 Apr 2016 07:30:01 +0200] rev 29284
update: fix bare --clean to work on new branch (issue5003) (BC) Before this commit bare update --clean on newly created branch updates to the parent commit, even if there are later commits on the parent commit's branch. Update to the latest head on the parent commit's branch instead. This seems reasonable as clean should discard uncommited changes, branch is one of them.
Fri, 03 Jun 2016 15:55:07 +0200 revert: use "discard"/"revert" verb when reverting interactively (issue5143)
Denis Laxalde <denis.laxalde@logilab.fr> [Fri, 03 Jun 2016 15:55:07 +0200] rev 29283
revert: use "discard"/"revert" verb when reverting interactively (issue5143) Instead of "record this change to 'FILE'?" now prompt with: * "discard this change to 'FILE'?" when reverting to the parent of working directory, and, * "revert this change to 'FILE'?" otherwise.
Tue, 05 Apr 2016 01:35:58 +0000 run-tests: add support for RTUNICODEPEDANTRY environment variable
timeless <timeless@mozdev.org> [Tue, 05 Apr 2016 01:35:58 +0000] rev 29282
run-tests: add support for RTUNICODEPEDANTRY environment variable based on 73e4a02e6d23
Fri, 27 May 2016 05:24:45 +0000 obsolete: fix grammar
timeless <timeless@mozdev.org> [Fri, 27 May 2016 05:24:45 +0000] rev 29281
obsolete: fix grammar
Sun, 03 Apr 2016 20:49:30 +0000 tests: add run-test .testtimes basic testing
timeless <timeless@mozdev.org> [Sun, 03 Apr 2016 20:49:30 +0000] rev 29280
tests: add run-test .testtimes basic testing
Tue, 31 May 2016 21:02:30 +0900 check-code: make repquote distinguish more characters for exact detection
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 31 May 2016 21:02:30 +0900] rev 29279
check-code: make repquote distinguish more characters for exact detection This patch makes repquote() distinguish more characters below, as a preparation for exact detection in subsequent patch. - "%" as "%" - "\\" as "b"(ackslash) - "*" as "A"(sterisk) - "+" as "P"(lus) - "-" as "M"(inus) Characters other than "%" don't use itself as replacement, because they are treated as special ones in regexp.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip