Wed, Sep 27
I missed your question in (1). A typical scenario for this would be when working on a feature which requires some refactoring work to be done. A revision is created with just the refactoring work and then a dependent revision is made which includes the actual feature work. During feature work additional refactoring might be made and need to update to that changeset and either add/amend changes, rebase the dependent revision back on top. Having the bookmarks auto created would help especially when using arc:bookmark when updating revisions back to phab.
Sep 19 2017
Sep 5 2017
See also PHI45.
Aug 27 2017
The behavior may have changed, but the change is from "we sometimes silently do the wrong thing" to "we explicitly refuse to do the wrong thing".
Ah, it sounded like a regression from the report. I haven't tried to bisect to determine if that was true.
That is, specifically, it expected that hg commands do not work in Phabricator if it can not determine the version of hg, so this is not a bug. Ignoring the setup warning might mean "we used to do Mercurial stuff but don't anymore, leaving us with some archived Mercurial repositories which we don't really need to look at, so it's okay that hg commands won't be able to run".
The version is strictly required because different versions of hg use different command syntax. If we can not determine which version of hg is installed, we can not run hg commands.
Aug 14 2017
There doesn't seem to be anything actionable remaining on our end.
Aug 11 2017
This cropped up in the HN thread -- works in my browsers (although Phabricator does not recognize it as a valid link):
Thanks for the writeup :)
The reason the upstream projects aren't using -- is that it isn't portable. For example, Putty's ssh doesn't support it.
The full set of mitigations is now available in stable, and I've promoted 2017 Week 32 (Mid August).
See also this enormously valuable contribution I made to the Git LFS upstream in connection with T7789 some time ago:
Thanks for the detailed explanations! I should have thought more carefully. Note old Mercurial also fails to do correct shell quoting on Windows (It uses ' where Windows needs "). But Phabricator does not run on Windows, it shouldn't be an issue.
So, all three major VCS had the exact same CVE, which was "we invoke ssh command line, don't sanitize input, and don't specify -- anywhere"?
@indygreg Thanks for the heads up about subrepos -- I would not have otherwise guessed that hg pull might run git.
From this writeup:
The magic incantation I arrived at was slightly modified from one of the hg test cases:
Never mind, I was able to get hg pull -u to interact. I'm going to land, cherry-pick, and hotfix D18390.
I think this is related:
And here's an extension which appears to be aimed at solving this problem, by adding a new command to execute hg pull -u in subrepositories:
Also, although ui.ssh appears inneffective against the [git] and [svn] variants of subrepos (Mercurial does not appear to populate GIT_SSH or SVN_SSH based on the ui.ssh setting), I can't get hg to actually interact with remotes using hg clone --noupdate ... or hg pull -u -- <uri>, which are the only relevant commands we run. I can get it to interact with remotes with hg up or hg clone (without --noupdate).
In the example above, I put malicious content in .hgsub, like this:
The subrepo issue is when .hgsub has malicious content (ex. foo = ssh://-oProxyCommand=touch%20BAR/). It's not related to command line or config files.
I'm going to cherry-pick rP794e185bf90e (the SSH wrapper stuff) to stable and hotfix production, although I'm not entirely certain hg pull -u -- <uri> is vulnerable.
I also can't get hg pull -u -- <uri> to fetch subrepos, am I just not setting things up correctly? In my current working state, hg up tries to interact with the subrepo remote but hg pull -u -- <uri> (which is what we actually execute) does not.
See also T4416. Removing -u hasn't been a priority because no actual install has expressed interest in it.
Aug 10 2017
That same code I pointed to for Mercurial also seems to perform Git working copy checkouts. Although I can't recall Git's semantics for automatically updating submodules (because I don't use them). It is worth auditing.
Note that Phabricator can manifest Mercurial working directories. See executeMercurialUpdate() in src/applications/repository/engine/PhabricatorRepositoryPullEngine.php. It does this when pulling non-hosted repos. I know this occurs when observing repos. Not sure where else this code is used.
I'll leave this open until I write up the release notes since it deserves a mention (users are still vulnerable if an attacker tricks them into running a suspicious git clone command), but I think we're otherwise unscathed by this.