Not all applications have full policy support yet, usually because it's blocked by something or they're beta.

For what is worth, I believe the main use case for this are Maniphest tasks: someone complaining about X in social media or tools like Discourse, then someone replies pointing to a related Phabricator task.

In T12098#233396, @sshannin wrote:

Obviously not a particularly important issue, but this now will populate a link in the favorites menu which leads to an exception:

I'm unable to close this, but I believe this to be resolved (or at least my specific repro of flags via herald no longer applies I believe).

Obviously not a particularly important issue, but this now will populate a link in the favorites menu which leads to an exception:

I backed out the earlier changes since I'm not sure when this will move forward, but:

@epriestley thank you very much for looking into this so quickly and in such detail. I fully understand that it is not worth investing a lot on this task. I thought this would be almost an easyfix, and I have learned something understanding the complexities (and the fact that OneBox hardcodes quite a bit of the fancy boxes).

After spending a couple hours on this, I more or less understand what we have to do, but it isn't entirely straightforward.

This can be "fixed" like this:

Phabricator messes up tab spacing in patches. It should be very easy to replace tabs with spaces and require the use of only monospace fonts.

That's a good point! I wish it was designed like that since the beginning. I guess it won't happen with the current compatibility rules since it is likely to break automation.

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

https://phab.mercurial-scm.org/D1483 should make it possible to use -- to defend against non-flag user input. For inputs that are flags, use the form --flag=X and avoid --flag X.

Hi Epriestley,

@epriestley I tried submitting a patch, but I get a Permission denied (publickey) which results in Unable to push changes to the staging area..
I added my public key and created a config rule to use it for requests to secure.phabricator.com, I'm not sure what else to do.

So, to recap:

• PhpunitTestEngine::run must be updated to use --log-junit which will output XML instead of JSON
• ArcanistPhpunitTestResultParser::parseTestResults must be updated to parse this XML file.

This seems simple enough, I will try to make it work.

I think that's possible in Phabricator's workboards, too? I can set a workboard to be sorted by priority, but then I can still drag tasks around to change their order within the column. (But if I drag a High priority task to below a Normal priority task, Phabricator automatically changes it to Normal priority.)

Fixed! Thanks again for the report.

Thanks; good catch. Fixing now.

https://phacility.com/ is still giving ssl error - it's net::ERR_CERT_COMMON_NAME_INVALID, I think (Maybe *.x doesn't cover x?)

Ok, I received a follow-up from support and it's working again.

This doesn't appear to be working. My team is reporting lots of problems with certificate errors with our hosted instance. It was working for me in Chrome as long as I was signed in, but opening a private tab I was redirected to admin.phacility.com and received an error there that the cert had expired.

I'm just an end user. But I fully agree with that. Using a priority to set a status always confused me. In JIRA it works more intuitive. A task starts in the backlog, and when touched it will be pushed to status open. When somebody accepts and starts the task, it will be moved into "In progress". And the priority can be from low to high. I like Phabricator very much, but in JIRA the Boards with ranking (ranking is not a priority) you actually can set the order of the tasks in a priority group.

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

I don't see this increasing storage usage - just shifting it. Right now because Phacility doesn't support LFS, all those large files are going straight into Git, which not only ends up on an EBS SSD, but also has to be cloned every single time which increases bandwidth usage. At least with LFS those costs are going to be from S3 (which I believe is cheaper than EBS SSD per GB), and bandwidth would be down as new clones no longer need to pull every version of a large file in the Git history.

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.

Thank you. Will update the WMF task with this information.

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: