Practically, msortv() and PhutilSortVector are now the solution here. They provide high-performance (no usort*()), multi-dimensional, stable, explicitly typed sort.

Just sweeping this up, rewriting the property display to show +x seems reasonable to me but I think it's self-evident enough that we don't need to keep a task around for it.

I don't think this meets the high bar required by modern feature requests (see "Upstreamable Feautures" in Planning).

(This isn't anything upstream-actionable.)

This seems to have calmed down.

We appear to have survived this. D18398 removed the double writes. There's a bit more cleanup (we could remove the edge type and actually destroy the older data) but that can happen whenever we get around to it.

This is five years old, and doesn't meet the requirements of a modern feature request. If you're still interested in this, feel free to start a new discussion on Discourse.

This doesn't meet the criteria of a modern feature request and predates significant changes to the inline comment UI. If this is still an issue, feel free to start a new discussion on Discourse.

Closing this for lack of feedback, feel free to resurrect it if you get back to it.

This isn't a bug; they aren't subscribers, and aren't listed in "Subscribers" in the right-hand column or in "Subscribers" in "Edit Task".

I don't think this clearly describes a root problem. PHI33 touches on similar issues, and I'll file something vaguely in this realm if anything comes of that.

I just clicked through it, I don't think there's any reason for staff to be there normally.

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

We still get a tiny mess where administrators clicking "pin" might mean "pin by default for all users" or "pin by default for just me" but that's reasonable to clarify in the workflow.

Currently, users may hide or reorder builtin queries. With the simplest version of the plan above, users will lose that ability: builtin queries will always be visible (unless hidden by an administrator) and always at the bottom of the list.

@aubort, please use the community forum (see: Discourse) if you'd like to discuss this issue.

@aleb, if you like to continue discussion of this please use the appropriate channels, as @chad suggested above (at the time, they were Conpherence and Ponder, but the appropriate channel is now the community forum -- see: Discourse).

In https://hackerone.com/reports/259246 (not currently disclosed) a researcher found an actual issue with figlet. Although it would probably be hard to develop into a practical attack, it does make me feel better about the decision to pull all this stuff into PHP (not just dot) when the dot issue was originally identified.

I've landed the two scary migration changes (D18418, D18419) and deployed them here without any obvious issues arising. The actual effects here are:

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