We've seen a couple of flavors of this from @swisspol, too. Although the symptom there is a little different (not a policy issue, exactly), the root cause is mostly similar. In particular, we saw:

• One case of a user using an SSH alias to alias something like repo to full-long-name.fancy-host.com; see also T11882. arc can not translate SSH aliases so it could not figure out that git://repo/X/ is the same as git://full-long-name.fancy-host.com/X/.
• One case of a user using a personal GitHub fork as a remote. arc can not reasonably recognize that git://github.com/X/Y.git and git://github.com/Z/Y.git are the same in the general case, and it would sometimes be wrong if it tried to infer this from available information (that is, even if it made calls to the GitHub API to see that "Z" was truly a fork of "X", this is not sufficient to unambiguously identify user intent).

No matter what the case, the affected user (or users) can run arc which to figure out why the repository is not being identified. This might be because they're using an SSH alias, or a personal fork, or for some other reason.

The easiest way to fix this is usually to add "repository.callsign" to .arcconfig, which will unambiguously bind the working copy to a Diffusion repository.

I think a blanket way to stem the bleeding here is to write this Herald rule:

Global Rule for Differential Diffs
When:
[ Repository ] [ does not exist ]
Take these actions:
[ Block diff with message ] [ "Repository unrecognized. See https://helpful-docs.com/repository-help for details." ]

That link could point users at documentation which says stuff like:

• Maybe add repository.callsign to .arcconfig.
• Maybe run arc which.
• Maybe don't use SSH aliases / personal forks.

The exact instructions would depend on your install, but if you write this rule it should prevent users from disclosing information by accident.

Also note that I plan to replace "repository.callsign" with something like "repository" "soon", which will accept a callsign, ID, short name, or monogram.

A possible change here is to make some global option available like "Always Require a Repository". The reason we don't require a repository is to ease onboarding: in some environments, it's a lot simpler to evaluate Phabricator or deploy it alongside other software if it doesn't have to touch repositories and can purely layer on top of them. It's also occasionally useful to, e.g., create changes from third-party repositories in an ad-hoc way (e.g., to discuss a problem in a dependency or whatever).

We could let installs configure a "require a repository" option, but if it's on-by-default it partly defeats the purpose of easing onboarding, and if it's off-by-default it would likely be only somewhat less obscure than the Herald rule. Plus, T8227.

We could do something like prompting users, but in his case (where the repository is important for security reasons) it's particularly bad to let users "y" through an "ignore security" prompt. So you'd still have to back it up with something like the Herald rule.

In Git and Mercurial, we could also try to use commit hashes to identify a repository (we already use UUIDs for Subversion, I believe). However, I worry this may lead to significantly more false positives than the current URI-based repository identification schemes. Still, maybe worth looking into.

I had indeed implemented precisely that herald rule once I realized that these diffs were being created without repository info attached. I also added repository.callsign to /etc/arcconfig to eliminate the problem going forward.

That roughly fixes the issue going forward (for me at least). My main issue now is how to gracefully handle the existing differential items s.t. I can apply a Space policy to them (i.e. is there a graceful way to backfill or to infer the space from the commit that eventually showed up).

See also PHI1987 for another case of this.