Wed, 30 Jan 2019 09:52:16 -0800 tests: add b'' prefixes to badserverext.py
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 30 Jan 2019 09:52:16 -0800] rev 41463
tests: add b'' prefixes to badserverext.py This avoids a handful of failures due to missing str and bytes. # skip-blame: just a bunch of b'' prefixes Differential Revision: https://phab.mercurial-scm.org/D5750
Wed, 30 Jan 2019 11:44:34 -0800 hgweb: log error before attempting I/O
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 30 Jan 2019 11:44:34 -0800] rev 41462
hgweb: log error before attempting I/O Previously, an uncaught exception during HTTP request serving would attempt to send an error response then log the exception. If an exception occurred during I/O, this exception would be raised and the original exception wouldn't be logged. This commit changes behavior so the original exception is logged first, before we attempt to do anything else. This ensures the exception is logged. This change resulted in new tracebacks appearing in various tests. Because tracebacks can vary between Python versions, we added a simple script to filter the stack part of traceback lines. This makes testing much simpler, as we don't need to glob over lines and make lines conditional. Differential Revision: https://phab.mercurial-scm.org/D5749
Tue, 29 Jan 2019 11:51:19 -0800 tests: write commit message using file I/O
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 29 Jan 2019 11:51:19 -0800] rev 41461
tests: write commit message using file I/O Python 2.7 will print() \x94\x5c\x0a whereas Python 3 will print() \xc2\x94\x5c\x0a. Why, I'm not sure. It probably has to do with print() being Unicode aware on Python 3 and Python attempting some kind of encoding before emitting the output. This difference results in a different bytes making it to the commit message and the JSON output varying. We work around this by writing bytes to a commit message file. Differential Revision: https://phab.mercurial-scm.org/D5741
Fri, 01 Feb 2019 13:44:09 -0500 Added signature for changeset 83377b4b4ae0 stable
Augie Fackler <raf@durin42.com> [Fri, 01 Feb 2019 13:44:09 -0500] rev 41460
Added signature for changeset 83377b4b4ae0
Fri, 01 Feb 2019 13:44:07 -0500 Added tag 4.9 for changeset 83377b4b4ae0 stable
Augie Fackler <raf@durin42.com> [Fri, 01 Feb 2019 13:44:07 -0500] rev 41459
Added tag 4.9 for changeset 83377b4b4ae0
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
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip