...

See PHI372 -- setting user.custom-field-definitions (or, probably, any similar config) to a string will pass validation but then fatal in use.

One attack is that you can override the content of email and then send invite or welcome mail that says whatever you want, whether the victim has a Phabricator account (welcome) or not (invite).

This could also just go on the existing page at the bottom. We tell people to copy/paste it when submitting bug reports, but it's probably fine if they're including more information, especially since there is a nice walled garden moat around my personally having to deal with it.

See also PHI22.

One of our engineers is having a similar issue with slightly different error, running "arc install-certificate" would always fail with the following error:

• PhabricatorSyntaxHighlightingConfigOptions defines this option.
• Change the type from wild to custom:SomeClassName to switch to a custom type validator.
• The new validator class should subclass PhabricatorConfigJSONOptionType.
• You can look at PhabricatorKeyringConfigOptionType for a (more complex) example of how to validate a value.
• Test by trying to change the value to something invalid, you should get an error.
• You can test a regexp is valid like this:

I think I'm just going to remove the "profile picture" text from the description to resolve this. The account.editable option is very old and I'd eventually like to remove it, but making the description more clear is an easier fix for now.

Righty; I didn't want to create any extra noise. New ticket, ho.

If you'd like us to look at it, please file a new issue following Contributing Bug Reports.

arcanist: ade25facfdf22aed1c1e20fed3e58e60c0be3c2b
libphutil: 9d85dfab0f532d50c2343719e92d574a4827341b
phabricator: 2d4eb460abb2ba34a944962c7cfea5741e099ff9

That's similar but not directly related.

Getting another instance of what looks to be a similar issue but for a different function, specifically

The "Public" vs "All Users" stuff is sort of a confusing behavior on our part (the workflow is what set "Public", which doesn't really make sense given the rest of your config) but I think it's largely mooted by the fix in D17011, and to be more clear about it we'd have to make this one particular file magical somehow (we can't choose either "users" or "public" as the policy unambiguously, because the install may change the value of policy.allow-public later without also updating the logo).

Oh. No - no it doesn't.

No problem -- we gave you a false start in Q528 and this behavior is pretty hard to guess at if you don't know the internals.

OK, after removing the custom logo (even though it's Public) I can't replicate any more.

Same file.

Specifically, this is the PHID you're looking for in the UI:

If you do this:

Well, the fact that the logo isn't restricted:

When you say "fail hard", you specifically mean that you get an exception message beginning with this text?

Um. That's a different bug to the one I'm reporting. The custom logo I have set is visible to Public.

Another workaround is directly editing the Phabricator database (e.g. with phpMyAdmin).

I think the remaining part was "show a lot more versions of different things", but I can't immediately think of cases where that would have helped us resolve something faster.

Resolved?

@epriestley I think that's a massive underestimation of the prevalence of the Atom editor. It has a pretty large user base.

We haven't seen requests for this from other installs and I don't particularly favor this mechanism. Prior alerts in this vein like "daemon and web config differ" have created a lot of noise and little value. T7338 should eventually provide more monitoring tools.

(That's not possible for all issues, like the conduit.deprecated.* issues, since those no longer fire.)

We should probably provide a way to do this, but a workaround today is: