Mon, 31 Jul 2017 14:55:11 -0700 subrepo: add tests for git rogue ssh urls (SEC) stable
Sean Farley <sean@farley.io> [Mon, 31 Jul 2017 14:55:11 -0700] rev 33642
subrepo: add tests for git rogue ssh urls (SEC) 'ssh://' has an exploit that will pass the url blindly to the ssh command, allowing a malicious person to have a subrepo with '-oProxyCommand' which could run arbitrary code on a user's machine. In addition, at least on Windows, a pipe '|' is able to execute arbitrary commands. When this happens, let's throw a big abort into the user's face so that they can inspect what's going on.
Mon, 31 Jul 2017 16:44:17 -0700 subrepo: add tests for svn rogue ssh urls (SEC) stable
Sean Farley <sean@farley.io> [Mon, 31 Jul 2017 16:44:17 -0700] rev 33641
subrepo: add tests for svn rogue ssh urls (SEC) 'ssh://' has an exploit that will pass the url blindly to the ssh command, allowing a malicious person to have a subrepo with '-oProxyCommand' which could run arbitrary code on a user's machine. In addition, at least on Windows, a pipe '|' is able to execute arbitrary commands. When this happens, let's throw a big abort into the user's face so that they can inspect what's going on.
Mon, 31 Jul 2017 16:04:44 -0700 subrepo: add tests for hg rogue ssh urls (SEC) stable
Sean Farley <sean@farley.io> [Mon, 31 Jul 2017 16:04:44 -0700] rev 33640
subrepo: add tests for hg rogue ssh urls (SEC) 'ssh://' has an exploit that will pass the url blindly to the ssh command, allowing a malicious person to have a subrepo with '-oProxyCommand' which could run arbitrary code on a user's machine. In addition, at least on Windows, a pipe '|' is able to execute arbitrary commands. When this happens, let's throw a big abort into the user's face so that they can inspect what's going on.
Mon, 31 Jul 2017 14:40:28 -0700 push: add tests for unsafe ssh url (SEC) stable
Sean Farley <sean@farley.io> [Mon, 31 Jul 2017 14:40:28 -0700] rev 33639
push: add tests for unsafe ssh url (SEC)
Fri, 28 Jul 2017 16:47:32 -0700 pull: add tests for unsafe ssh url (SEC) stable
Sean Farley <sean@farley.io> [Fri, 28 Jul 2017 16:47:32 -0700] rev 33638
pull: add tests for unsafe ssh url (SEC)
Fri, 28 Jul 2017 16:36:36 -0700 clone: add tests for unsafe ssh url (SEC) stable
Sean Farley <sean@farley.io> [Fri, 28 Jul 2017 16:36:36 -0700] rev 33637
clone: add tests for unsafe ssh url (SEC)
Tue, 01 Aug 2017 14:40:19 -0700 sshpeer: check for safe ssh url (SEC) stable
Sean Farley <sean@farley.io> [Tue, 01 Aug 2017 14:40:19 -0700] rev 33636
sshpeer: check for safe ssh url (SEC) Checking in the sshpeer for a rogue ssh:// urls seems like the right place to do it (instead of whack-a-mole with pull, clone, push, etc).
Fri, 04 Aug 2017 14:00:03 -0400 ssh: ban any username@host or host that starts with - (SEC) stable
Augie Fackler <augie@google.com> [Fri, 04 Aug 2017 14:00:03 -0400] rev 33635
ssh: ban any username@host or host that starts with - (SEC) This paranoia probably isn't required, but it can't hurt either.
Fri, 28 Jul 2017 16:32:25 -0700 util: add utility method to check for bad ssh urls (SEC) stable
Sean Farley <sean@farley.io> [Fri, 28 Jul 2017 16:32:25 -0700] rev 33634
util: add utility method to check for bad ssh urls (SEC) Our use of SSH has an exploit that will parse the first part of an url blindly as a hostname. Prior to this set of security patches, a url with '-oProxyCommand' could run arbitrary code on a user's machine. In addition, at least on Windows, a pipe '|' can be abused to execute arbitrary commands in a similar fashion. We defend against this by checking ssh:// URLs and looking for a hostname that starts with a - or contains a |. When this happens, let's throw a big abort into the user's face so that they can inspect what's going on.
Wed, 26 Jul 2017 22:10:15 +0900 pathauditor: disable cache of audited paths by default (issue5628) stable
Yuya Nishihara <yuya@tcha.org> [Wed, 26 Jul 2017 22:10:15 +0900] rev 33633
pathauditor: disable cache of audited paths by default (issue5628) The initial attempt was to discard cache when appropriate, but it appears to be error prone. We had to carefully inspect all places where audit() is called e.g. without actually updating filesystem, before removing files and directories, etc. So, this patch disables the cache of audited paths by default, and enables it only for the following cases: - short-lived auditor objects - repo.vfs, repo.svfs, and repo.cachevfs, which are managed directories and considered sort of append-only (a file/directory would never be replaced with a symlink) There would be more cacheable vfs objects (e.g. mq.queue.opener), but I decided not to inspect all of them in this patch. We can make them cached later. Benchmark result: - using old clone of http://selenic.com/repo/linux-2.6/ (38319 files) - on tmpfs - run HGRCPATH=/dev/null hg up -q --time tip && hg up -q null - try 4 times and take the last three results original: real 7.480 secs (user 1.140+22.760 sys 0.150+1.690) real 8.010 secs (user 1.070+22.280 sys 0.170+2.120) real 7.470 secs (user 1.120+22.390 sys 0.120+1.910) clearcache (the other series): real 7.680 secs (user 1.120+23.420 sys 0.140+1.970) real 7.670 secs (user 1.110+23.620 sys 0.130+1.810) real 7.740 secs (user 1.090+23.510 sys 0.160+1.940) enable cache only for vfs and svfs (this series): real 8.730 secs (user 1.500+25.190 sys 0.260+2.260) real 8.750 secs (user 1.490+25.170 sys 0.250+2.340) real 9.010 secs (user 1.680+25.340 sys 0.280+2.540) remove cache function at all (for reference): real 9.620 secs (user 1.440+27.120 sys 0.250+2.980) real 9.420 secs (user 1.400+26.940 sys 0.320+3.130) real 9.760 secs (user 1.530+27.270 sys 0.250+2.970)
Tue, 01 Aug 2017 21:03:25 +0900 tests: show cache of audited paths is never invalidated stable
Yuya Nishihara <yuya@tcha.org> [Tue, 01 Aug 2017 21:03:25 +0900] rev 33632
tests: show cache of audited paths is never invalidated
Thu, 10 Aug 2017 13:29:09 -0400 Added signature for changeset 5544af862286 stable
Augie Fackler <raf@durin42.com> [Thu, 10 Aug 2017 13:29:09 -0400] rev 33631
Added signature for changeset 5544af862286
Thu, 10 Aug 2017 13:29:08 -0400 Added tag 4.3 for changeset 5544af862286 stable
Augie Fackler <raf@durin42.com> [Thu, 10 Aug 2017 13:29:08 -0400] rev 33630
Added tag 4.3 for changeset 5544af862286
Mon, 07 Aug 2017 13:40:36 +0200 chg: define _GNU_SOURCE to allow CentOS 5 compilation stable 4.3
Mathias De Maré <mathias.de_mare@nokia.com> [Mon, 07 Aug 2017 13:40:36 +0200] rev 33629
chg: define _GNU_SOURCE to allow CentOS 5 compilation Without this flag, compilation fails with: hgclient.c: In function 'hgc_open': hgclient.c:466: error: 'O_DIRECTORY' undeclared (first use in this function) hgclient.c:466: error: (Each undeclared identifier is reported only once hgclient.c:466: error: for each function it appears in.) Differential Revision: https://phab.mercurial-scm.org/D260
Mon, 07 Aug 2017 13:38:25 +0200 centos5: use vault urls stable
Mathias De Maré <mathias.de_mare@nokia.com> [Mon, 07 Aug 2017 13:38:25 +0200] rev 33628
centos5: use vault urls CentOS 5 has reached end-of-life. A working build for it is still possible using 'vault.centos.org'. Differential Revision: https://phab.mercurial-scm.org/D261
Sat, 05 Aug 2017 13:19:09 -0700 ui: make sure buffer is flushed before waiting for user input (issue5587) stable
Kostia Balytskyi <ikostia@fb.com> [Sat, 05 Aug 2017 13:19:09 -0700] rev 33627
ui: make sure buffer is flushed before waiting for user input (issue5587) Without this patch on Windows 'hg ci -i' hangs waiting for user input and "examine changes to 'file'? [Ynesfdaq?]" is never displayed (at least if the diff is sufficiently small). When Ctrl+C is pressed, this prompt becomes visible, which suggests that the buffer just wasn't flushed. I've never seen this happening on Linux, but this looks harmless enough to not platform-gate it.
Wed, 02 Aug 2017 22:51:19 +0900 util: fix sortdict.update() to call __setitem__() on PyPy (issue5639) stable
Yuya Nishihara <yuya@tcha.org> [Wed, 02 Aug 2017 22:51:19 +0900] rev 33626
util: fix sortdict.update() to call __setitem__() on PyPy (issue5639) It appears that overriding __setitem__() doesn't work as documented on PyPy. Let's patch it as before bd0fd3ff9916. https://docs.python.org/2/library/collections.html#ordereddict-examples-and-recipes The issue was ui.configitems() wasn't ordered correctly, so the pull command was wrapped in different order.
Wed, 02 Aug 2017 22:58:38 +0900 test-revlog-raw: close file handles explicitly (issue5644) stable
Yuya Nishihara <yuya@tcha.org> [Wed, 02 Aug 2017 22:58:38 +0900] rev 33625
test-revlog-raw: close file handles explicitly (issue5644)
Wed, 02 Aug 2017 22:04:02 +0900 tests: clear __pycache__ for PyPy compatibility (issue5638) (issue5642) stable
Yuya Nishihara <yuya@tcha.org> [Wed, 02 Aug 2017 22:04:02 +0900] rev 33624
tests: clear __pycache__ for PyPy compatibility (issue5638) (issue5642)
Wed, 02 Aug 2017 22:06:45 +0900 test-extension: glob module name in error message for PyPy stable
Yuya Nishihara <yuya@tcha.org> [Wed, 02 Aug 2017 22:06:45 +0900] rev 33623
test-extension: glob module name in error message for PyPy
Wed, 02 Aug 2017 21:52:22 +0900 rebase: sort collapsed revisions in commit message (issue5643) stable
Yuya Nishihara <yuya@tcha.org> [Wed, 02 Aug 2017 21:52:22 +0900] rev 33622
rebase: sort collapsed revisions in commit message (issue5643) This fixes the test instability.
Wed, 02 Aug 2017 00:02:11 +0900 i18n: use actual filename, in which function is defined, for hg.pot stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 02 Aug 2017 00:02:11 +0900] rev 33621
i18n: use actual filename, in which function is defined, for hg.pot Before this patch, source filename for msgid in hg.pot file becomes incorrect, if a function is defined in file A, but detected in dict in file B, For example, almost all debug* commands are defined in debugcommands.py, but hggettext detects them in "table" of commands.py. Therefore, docstring fragments of debug* commands are marked as "defined in commands.py" in hg.pot file. This is serious problem for translation, because the cost to find out original location of texts increases very much.
Tue, 01 Aug 2017 18:52:52 +0900 ui: enable pager always for explicit --pager=on (issue5580) stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 01 Aug 2017 18:52:52 +0900] rev 33620
ui: enable pager always for explicit --pager=on (issue5580) Before this patch, explicit --pager=on is unintentionally ignored by any disabling factor, even if priority of it is less than --pager=on (e.g. "[ui] paginate = off").
Thu, 20 Jul 2017 01:30:41 -0700 rebase: use one dirstateguard for when using rebase.singletransaction
Durham Goode <durham@fb.com> [Thu, 20 Jul 2017 01:30:41 -0700] rev 33619
rebase: use one dirstateguard for when using rebase.singletransaction This was previously landed as 2519994d25ca but backed out in b63351f6a2 because it broke hooks mid-rebase and caused conflict resolution data loss in the event of unexpected exceptions. This new version adds the behavior back but behind a config flag, since the performance improvement is notable in large repositories. The old commit message was: Recently we switched rebases to run the entire rebase inside a single transaction, which dramatically improved the speed of rebases in repos with large working copies. Let's also move the dirstate into a single dirstateguard to get the same benefits. This let's us avoid serializing the dirstate after each commit. In a large repo, rebasing 27 commits is sped up by about 20%. I believe the test changes are because us touching the dirstate gave the transaction something to actually rollback. (grafted from 9e3dc3a1638b9754b58a0cb26aaa75d868058109) (grafted from 7d38b41d2266d9a02a15c64229fae0da5738dcec) Differential Revision: https://phab.mercurial-scm.org/D135
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 +10000 tip