In theory, you could require --config appear between hg and foo in hg foo .... This is already a valid position for --config (for example, hg --config x=y foo is valid), and already not a valid position for foo flags (for example, hg --branch default log is not valid).

See also T6445 (SVG files) and T5258 (additional legacy cruft).

I think the current state of things is:

We'll use the hardened mode once it's available, but I don't think we expect to take any further action here until then.

The tools to perform this export are available in that project already. We don't plan to run the tools for you, since this just makes the workflow more complicated: you already have access to the tools you need to do this yourself.

This is now in master so I've made the task public.

I don't want to leave RCE in Phabricator for 3 weeks, so I'm planning to land, deploy and disclose some version of the patch above today.

(I change visibility for this to @epriestley, @amckinley and @durin42 for now -- note that I intend to eventually make this issue public once the fix hits the commit log, so don't stockpile all your 0-days here.)

This doesn't seem to have caused any issues.

The other major thing I tried was throwing exceptions when the values for %s, etc., contained --debugger or --config while constructing Mercurial commands.

I have a not-so-great patch for this ready when Mercurial makes a decision. This isn't great, but it's the best I could come up with after trying a few things.

In reply:

From @durin42, via Mercurial Security:

(Another possibility is to add behavior to arc to control this.)

Maybe. Another possibility is to mark builds as "nonblocking" in some sense. There are some other open requests for defining "advisory" or "noncritical" builds where build failure doesn't cause the Buildable to report a failed result overall. If we end up adding this state to builds anyway, it probably makes sense to include a "Does Not Block Review" flag to the "Does Not Fail Buildable" / "Does Not Block Dependent Builds" / "Failure Is Totally Meaningless" / Whatever flags.

Pretty sure T7704 is the same as this.

PHI181 has an entangling concern (T11372).

Generally, this sort of discussion is better on Discourse (https://discourse.phabricator-community.org) than here.

From T10109, we shouldn't make revisions "Buildable" to Herald if the update is an automatic update in response to a commit being discovered.

Ah, thanks. I think your guess is right. I'll make a note in T2543, should be a one-line fix I think.

After all that stuff:

Additionally, arc diff no longer dispatches ArcanistEventType::TYPE_REVISION_WILLCREATEREVISION if the server is sufficiently modern. (It no longer uses the datastructure this event received.)

See T2543. The flags related to previewing a diff have changed:

This is technically accurate but real awkward for humans:

I pushed secure004 with that patch and it worked fine, although mysql came back up fast enough that we didn't have to wait. Since I don't have a way to actually trigger this condition, I'm going to assume this is resolved until we have evidence otherwise.

This has been stable for about a week now.

This traffic eventually stopped on October 20th.

The pruned (at 0.15 threshold), optimized ngram index for the original affected instance is only ~13GB, which is entirely manageable with the changes to backups, and we haven't run into other issues.

We hit one of more of these (db024) last week so D18725 should fix it.

A very rough version of this is now in master, but only active if phabricator.show-prototypes is on. These are some of the (substantial) remaining issues I'm aware of, and there are probably others:

I'm going to call this tentatively done and leave it open for a week or two to see if there's any fallout.

Something is making a lot of requests