Tue, 08 Jan 2019 22:19:36 +0900 subrepo: reject potentially unsafe subrepo paths (BC) (SEC) stable 4.9
Yuya Nishihara <yuya@tcha.org> [Tue, 08 Jan 2019 22:19:36 +0900] rev 41458
subrepo: reject potentially unsafe subrepo paths (BC) (SEC) In addition to the previous patch, this prohibits '~', '$nonexistent', etc. for any subrepo types. I think this is safer, and real-world subrepos wouldn't use such (local) paths.
Tue, 08 Jan 2019 22:07:45 +0900 subrepo: prohibit variable expansion on creation of hg subrepo (SEC) stable
Yuya Nishihara <yuya@tcha.org> [Tue, 08 Jan 2019 22:07:45 +0900] rev 41457
subrepo: prohibit variable expansion on creation of hg subrepo (SEC) It's probably wrong to expand path at localrepo.*repository() layer, but fixing the layering issue would require careful inspection of call paths. So, this patch adds add a validation to the subrepo constructor. os.path.realpath(util.expandpath(root)) is what vfsmod.vfs() would do.
Tue, 08 Jan 2019 21:51:54 +0900 subrepo: extend path auditing test to include more weird patterns (SEC) stable
Yuya Nishihara <yuya@tcha.org> [Tue, 08 Jan 2019 21:51:54 +0900] rev 41456
subrepo: extend path auditing test to include more weird patterns (SEC) While reviewing patches for the issue 5739, "$foo in repository path expanded", I realized that subrepo paths can also be cheated. This patch includes various subrepo paths which are potentially unsafe. Since an expanded subrepo path isn't audited, this bug allows symlink check bypass. As a result, a malicious subrepository could be checked out to a sub tree of e.g. $HOME directory. The good news is that the destination directory must be empty or nonexistent, so the existing ~/.bashrc wouldn't be overwritten. See the last part of the tests for details.
Thu, 31 Jan 2019 13:32:21 +0800 copyright: update to 2019 stable
Anton Shestakov <av6@dwimlabs.net> [Thu, 31 Jan 2019 13:32:21 +0800] rev 41455
copyright: update to 2019 Differential Revision: https://phab.mercurial-scm.org/D5779
Mon, 28 Jan 2019 18:00:14 -0800 patch: handle 0 context lines (diff.unified=0) when parsing patches
Kyle Lippincott <spectral@google.com> [Mon, 28 Jan 2019 18:00:14 -0800] rev 41454
patch: handle 0 context lines (diff.unified=0) when parsing patches Previously, if there were no context lines, we would just keep updating the ranges and the hunk, but not actually storing the hunk (just overwriting it each time). Thus a diff like this: $ hg diff --config diff.unified=0 diff --git a/bar b/bar --- a/bar +++ b/bar @@ -1,0 +2,1 @@ 1 +change1 @@ -3,0 +5,1 @@ 3 +change2 would come out of the parser like this (change1 is lost): bar: @@ -3,0 +5,1 @@ 3 +change2 This had some really weird side effects for things like commit --interactive, split, etc. Differential Revision: https://phab.mercurial-scm.org/D5743
Wed, 30 Jan 2019 03:56:35 +0530 py3: pass str into RuntimeError() to prevent b'' in output
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 30 Jan 2019 03:56:35 +0530] rev 41453
py3: pass str into RuntimeError() to prevent b'' in output # skip-blame as just r'' prefixes Differential Revision: https://phab.mercurial-scm.org/D5740
Wed, 30 Jan 2019 03:49:56 +0530 py3: use '%d' instead of '%s' for integers
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 30 Jan 2019 03:49:56 +0530] rev 41452
py3: use '%d' instead of '%s' for integers Differential Revision: https://phab.mercurial-scm.org/D5738
Tue, 29 Jan 2019 13:26:18 -0500 tests: port test-hgweb-auth.py to Python 3
Augie Fackler <augie@google.com> [Tue, 29 Jan 2019 13:26:18 -0500] rev 41451
tests: port test-hgweb-auth.py to Python 3 Differential Revision: https://phab.mercurial-scm.org/D5736
Tue, 29 Jan 2019 13:25:21 -0500 url: convert some variables back to bytes
Augie Fackler <augie@google.com> [Tue, 29 Jan 2019 13:25:21 -0500] rev 41450
url: convert some variables back to bytes Differential Revision: https://phab.mercurial-scm.org/D5735
Tue, 29 Jan 2019 13:24:20 -0500 url: add some defensive asserts on expected incoming types
Augie Fackler <augie@google.com> [Tue, 29 Jan 2019 13:24:20 -0500] rev 41449
url: add some defensive asserts on expected incoming types Our type handling is a nightmare here, and we're loading passwords to do network IO, so we can afford to be potentially-slow but pedantic here. Differential Revision: https://phab.mercurial-scm.org/D5734
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip