Thanks for the report! I think this should be fixed in HEAD of master. Let us know if that doesn't work or you run into anything else.

Same problem :
Versions :
phabricator bc3ac3158448dfe966d05787fa9272f08ddc7faa (Fri, Jul 1)
arcanist 4d4d16f25985f133501f20fdddd183e525f00341 (Wed, Jun 29)
phutil dde2f74f2793f0216f0d76618ed335a9c802cfec (Fri, Jul 1)

For reference, @Danny_B filed a copy of this on HackerOne here so I could award a bounty for it:

Also worth noting is that Content Security Policy (T4340) would have prevented this. CSP is obviously worth implementing, but I believe the last attack it would have prevented was D4534 in January 2013, so it's hard to prioritize if it only defuses one attack every 3-4 years.

The Phacility cluster has been patched.

In the future, please report security issues via HackerOne:

This is impossible.

Basic support to (hopefully) support svnsync is now deployed. The Herald stuff would be nice to have eventually, but we don't currently have any real use cases for it.

I can't reproduce this on the linked install or locally either; presuming we fixed it at some point.

This is sort of resolved since Diffusion moved to PHUITwoColumnView and project tags are now listed in the sidebar, labeled "Tags", while VCS tags are listed in the main list, also labeled "Tags". Labeling them both "tags" isn't great, but context provides some help and this doesn't immediately appear to be particularly confusing.

Yeah, this is a little obscure since I was trying not to build more than we needed. The URI comes from DiffusionRepositoryManagementPanel->newEditEnginePage(), which does this:

I dinked around on this but for the life of me, can't find where it's getting the URI from. I did learn how paging works in EditEngine though.

Thanks, this is working now.

Let me know if that doesn't fix things. Expected behavior is:

Thanks for all the help digging into this, there is pretty much zero chance I would have guessed that on my own. I think D16149 should fix this properly, I was able to reproduce a similar error once I knew what I was after.

Ah sorry for the confusion. I was trying to keep up to date on the weekly updates and didn't realize this flow had changed. I'll look at upgrading in the following week or two.

There are two completely different flows. At HEAD, the flow is entirely different and uses none of the same code.

there's no way to change "Edit Policy" from the initial form page

Is that not the same thing as "Editable By" during repository creation?

This would work now, except that there's no way to change "Edit Policy" from the initial form page.

Nevermind I am wrong. Anyways, @epriestley can explain policies better. I think this is correct on our side.

If I set "Can Edit" to Noone and "Can Create" to Admins, I can create repositories. But this is current Phabricator.

Yea I'm really sorry about March 4th. I'll probably look at upgrading in the following weeks. I slowed down updating because of the new UI layout to differential revisions which I thought would upset some people, needed to wait for warmer weather, etc. :x)

Anyways... this sounds correct. Why should a user be able to create something they can't edit?

March 4th?

I can't reproduce this on your linked install.

I think this is resolved, but see T9028 for related followups.

Can anyone interested in this explain the use case for making it per-Herald or per-user instead of global? Are half your users bitterly opposed to inline diffs, even after we fixed the Differential ones to not be terrible (T10694)?

I'm going to merge this into T9028. Specifically, daemons should be able to permanently fail operations on unreachable commits after D16131. That task discusses deleted/unreachable commits more broadly.

We can't reproduce this, so we can't move forward. Feel free to open a new issue if you are able to provide reproduction steps.

This fix appears to be holding.

I'm going to merge this into T9028. Specifically, D16133 rebuilds the summary table after any commit becomes unreachable, which should produce the correct commit count and other summary details.

black-listing phabricator/ sounds good to me :)

D16134 just hard-codes phabricator/ tags as untracked, which should minimize collateral damage.

Yeah, the actual rule D16129 implements is this:

In T6878#180701, @epriestley wrote:

For now, I think we can assume tags are always autoclose/track, but may need to refine this in the future.

"Autoclose" and "Track Only" configurations are limited to branches, and do not account for arbitrary tags/refs. For now, I think we can assume tags are always autoclose/track, but may need to refine this in the future. I'd ideally like to replace autoclose with "fork" (T10691) rather than introducing tag(regexp(...)) or whatever, but that may be a long road.

I know you have focussed on the missing background, but I'm not overly fussed about that. But I am surprised that the commit subject shown twice in a row, once truncated inside a table and once not, is anything else but a bug.

I know I didn't retrieve all the info you asked for, so let me know if you want to see anything else or want me to decode the base64 email body.

I've learned some interesting things.

Can you provide:

Thanks. That trace is consistent with the one I was able to reproduce, so I suspect the changes above fix this. I'll leave this open for a bit in case anyone else shows up, this fix is the kind of fix that's likely to have spooky side effects.

The command output was:

[2016-06-13 17:45:26] EXCEPTION: (InvalidArgumentException) Argument 1 passed to DiffusionCommandEngine::setURI() must be an instance of PhutilURI, instance of PhutilGitURI given, called in /home/ubuntu/phabricator/src/applications/repository/storage/PhabricatorRepository.php on line 511 and defined at [<phutil>/src/error/PhutilErrorHandler.php:200]
arcanist(head=stable, ref.master=e8a0ebaeffaa, ref.stable=7b0aac5c6f31), phabricator(head=1558175ec84c7b13ba3f692b897464901bc00578, ref.master=55767aac0f86, custom=2), phutil(head=stable, ref.master=dad3ab8d7e87, ref.stable=ad458fb7df59)
  #0 PhutilErrorHandler::handleError(integer, string, string, integer, array) called at [<phabricator>/src/applications/diffusion/protocol/DiffusionCommandEngine.php:52]
  #1 DiffusionCommandEngine::setURI(PhutilGitURI) called at [<phabricator>/src/applications/repository/storage/PhabricatorRepository.php:511]
  #2 PhabricatorRepository::newRemoteCommandEngine(array) called at [<phabricator>/src/applications/repository/storage/PhabricatorRepository.php:497]
  #3 PhabricatorRepository::newRemoteCommandFuture(array) called at [<phabricator>/src/applications/repository/storage/PhabricatorRepository.php:488]
  #4 PhabricatorRepository::getRemoteCommandFuture(string, string) called at [<phabricator>/src/applications/repository/engine/PhabricatorRepositoryPullEngine.php:350]
  #5 PhabricatorRepositoryPullEngine::executeGitUpdate() called at [<phabricator>/src/applications/repository/engine/PhabricatorRepositoryPullEngine.php:125]
  #6 PhabricatorRepositoryPullEngine::pullRepositoryWithLock() called at [<phabricator>/src/applications/repository/engine/PhabricatorRepositoryPullEngine.php:40]
  #7 PhabricatorRepositoryPullEngine::pullRepository() called at [<phabricator>/src/applications/repository/management/PhabricatorRepositoryManagementPullWorkflow.php:43]
  #8 PhabricatorRepositoryManagementPullWorkflow::execute(PhutilArgumentParser) called at [<phutil>/src/parser/argument/PhutilArgumentParser.php:410]
  #9 PhutilArgumentParser::parseWorkflowsFull(array) called at [<phutil>/src/parser/argument/PhutilArgumentParser.php:303]
  #10 PhutilArgumentParser::parseWorkflows(array) called at [<phabricator>/scripts/repository/manage_repositories.php:22]

The latest commit on stable fixes the problem for us 👍

I'm deploying this to the cluster now.

@ivo, if you see this before I post a fix, can you show me the output of this command so I can make sure I'm reproducing exactly the same issue?

This issue describes a narrow issue with typehinting URIs, introduced by T10227.

I'm going to merge this into T11137. They don't describe the same issue, but I'm planning to fix them in the same way.