(there's usually no value in reviewing individual file-level changes in a "create a new branch X" commit)

Completely agree that there's no value in reviewing those individually. But to be clear, my point in making this ticket was mostly that you can't discern from the browser that this was a "create a new branch" commit. Right now it just renders the whole file tree saying showing 3000 files individually copied instead of a simpler/single line saying the whole directory was copied.

I'm not aware of any current customer interest in improving this behavior, and it's likely a lot of work to improve what is largely a moot case (there's usually no value in reviewing individual file-level changes in a "create a new branch X" commit) that only affects Subversion.

There doesn't seem to be anything actionable remaining on our end.

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:

In T12961#230931, @avivey wrote:

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"?

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:
https://www.mercurial-scm.org/wiki/Subrepository#Synchronizing_in_subrepositories

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.

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.

We also used to have a separate PhutilGitURI which had looser rules, but I removed this in D16100 (June 13, 2016) and all URI parsing now goes through PhutilURI which has the stricter rules.

The theoretical attack here is:

These are slightly more fleshed-out versions of the attack in Mercurial:

git, svn, and hg... wow

The attack is basically:

oh wow

Solves things for my instances, cheers!

Going to keep this Open and build out some proper blank states. This feel pretty janky.

I pushed a hotfix up at HEAD of master, let us know if you're still having problems. Thanks for the report!

Doesn't sound like there is anything the upstream can do here.

Hm... the way we our systems folks have it installed it's apparently not a git repository. However, I was able to look in the src directory and found those lines in workflow/ArcanistCommitWorkflow.php. I'm checking with the person who ran the command that prompted me to make this feature request.

itsamystery

Expected output is similar to this:

What does git show show in arcanist/?

Oh! So it already has this feature! I wonder if perhaps we are on an old version. I tried arc version as specified here, but I just get an error:

The warning seems to be working properly for me locally, so I can't reproduce the issue if the claim is that it doesn't work:

Oh I was thrown off by the quotes and not a var.

I think it's right:

That pht seems to have too many %s ?

The expectation is that you should get this prompt when trying to arc commit a change you did not author:

It's very common to land other people's diffs (who do not have access to the repository) and comandeering changes the commit author.

Any idea of how to do this on CentOs?

@epriestley I'm in the process of setting up phabricator to help mature the development workflow based on svn here, and make future transitions to git/perforce easier. Changelists would be a natural path here but the workaround for our use case is to just manually specify paths, but it's annoying if you have a locally modified file that you accidentally include in a diff, since you *have* to revert it to remove it from the diff. Using a changelist would let you avoid making the mistake in the first place.