I'm just going to merge this into T929, I don't think it's a distinct task. I'll link that to T12824.

They should fix themselves once the instance is suspended.

This cropped up in the HN thread -- works in my browsers (although Phabricator does not recognize it as a valid link):

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

@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.

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:

I searched for .hgsub files containing URI paths matching ssh://- in working copies stored on disk to better assess the impact of the security issue described in T12961. I did not locate any.

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.

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:

The attack is basically:

oh wow

T12956 has another situation where letting MenuItem generate 2+ items may be bad: we want to let a menu item steal the selection, but it's muddy to implement if each MenuItem can return several actual views.

I believe the location of the OOM is a little misleading -- the real problem is loadFileData(). This returns the entire file as a string, and will thus:

The new rules on reports are still in flux a bit and extra-muddy for Community members, but I'd generally like to move to a "report + review" model for community reports, something like we currently have for code review. So the general idea is that your bug needs someone to review it and agree with it (e.g., reproduce a bug, or agree that a feature request is a brilliant new idea that makes sense and would be appropriate for the upstream and completely describes a reasonable, generally-experienced root problem) before it comes upstream.

I think this is a real bug. Here's a more complete example of what's going wrong, why it's wrong, and how to reproduce it.

The community forum is a better place for this discussion. You may or may not receive help there, but we're no longer providing general Phabricator support here in the upstream (nor have we for a long time).

Named queries will get a new flag like isGlobal

I'm not proposing that, no. Here's exactly what I'm proposing:

I wasn't planning to change the behavior of the dropdown, except that it would begin listing personal filters followed by global/default filters under "Saved Queries".

Where's the other conversation?

I think we should still default search the top item.

I don't think this is resolved, just an unclear report. To access this screen:

And one more, also for Kotlin.

D7150 added this text ("a revision's reviewers can always...") and I said it "wasn't true but would be soon", but never made it true.

Happy to take a look if you found a reasonable way to get access to $request. If you're reading $_REQUEST['__path__'] directly or something though the eventual upstream version probably won't look too similar.