4. As Alice, commandeer a revision authored by Baliey and reviewed by Claire. Edit it locally to do arbitrary bad things, then git push it.
5. Make a commit, edit the commit message to say Differential Revision: D1234, where D1234 is a current, valid, accepted revision authored by anyone, then git push it.

I believe it is extremely difficult to configure Phabricator to provide the assurance you describe, particularly if arc land does anything. If you are actually providing this guarantee ("an attacker needs two machines"), you can likely add a clause to the large amount of custom code you've written to prevent self-foisting while still supporting other foisting use cases. If you haven't written a large amount of custom code, I suspect an attacker can fairly easily deploy with one machine without using "Foist Upon".

Is there a way to disable this feature? Our security team has noticed that with this feature we can land code with just a single person's machine being compromised (we rely on an attacker needing two machines to deploy code as a safety mechanism). I.e. You make a revision, Foist it on someone, Approve it, then arc land it as the other person (saying y to the prompt).

This is now in stable; presuming it works until evidence to the contrary emerges.

The "Cancel" button should mean "Delete" if...

Currently, the inline code partially conflates four separate content states:

When you "Quote" a comment, then cancel, the comment disappears from the UI.

When you are viewing a change under engine X, and comments made under engine Y are present, they are not handled specially.

A general concern with "batch processing" is that it's quite bad if one commit failing to import can stall the entire repository forever.

See also T13552, which modifies the above discussion. The "Update" steps now happen after the "Publish" step.

The bulk of this work is done and I think there's nothing unique and actionable left here. This is survived by T13642 and other issues.

Survived by T13534, etc.

When you are viewing a document with engine X, and comments originally made with engine Y are present, this should be indicated ("This comment was made while looking at this change as a Q document."). They should probably also be moved to the top/bottom of the file, at least by default, since "Jupyter line number 9 = raw source line number 9" is an exceptionally bad and confusing guess at how to map line numbers.

Some tag stuff ended up here; I moved it to T13645.

• Colors are now consistent.
• Icons no longer use only color to communicate information.
• Icons are (mostly) consistent with the Harbormaster icons that have similar meanings.
• See Config → Modules/Extensions → Constants: Differential.

The diff above no longer reproduces this, and I think an equivalent to D18302 landed in D21178. T13524 was almost certainly the same issue.

This is mooted because I've removed the "excuses" feature about a year ago -- on the balance, I think it generated more confusion and busywork than signal.

The modern differential.revision.search API returns the repository for the revision.

See also PHI1910.

I think the complexity of changing this probably isn't worth the benefit. The complexity is high because of how much client-side interaction there is around inlines, and even with more space for the inline, the example screenshot doesn't seem great for code review anyway since none of the code fits.

In D21435, inlines were clamped. Adjusting this code is necessary, but not sufficient, to correct this problem.

(Internally, see PHI2020.)

This is relatively ripe for implementation now that inline comments support suggested edits.

This is very old, fairly vague, and doesn't have any clear modern customer interest. I'm open to implementing it, but would like a more clear/modern customer request before pursuing it.