• Try to come up with a way that - can do something dangerous when injected into a CSS rule.
  • See D7274#47131 for a template of how to attack this.
  • If you can come up with any attacks, don't implement this.
• Adjust the regular expression in PhabricatorMonospacedFontSetting::filterMonospacedCSSRule() to include -.
• Adjust the error text in PhabricatorMonospacedFontSetting->validateTransactionValue() to say "..., hyphens, ..." or similar.

I'm not entirely sure, but it seems plausible. We compute "Queue Utilization" as basically:

No, not updated yet.

Well, "trivial" might be a little ambitious.

Ah, thanks! That's a bug which we hadn't run into yet, but it's trivial to fix.

Okay. Can you run this command?

Oh, no, this is the right task. Your logs:

Someone has configured a bad Nuance source, so let's start by fixing that.

The reason we suggest @ as a delimiter is that you don't have to escape forward slashes if you use a delimiter other than /, so you get a more readable regexp.

I believe this is fine; I can't immediately come up with an attack using -.

Form (1) is expected to work, which is why we don't document a need for form (7): one is not expected to exist. If form (1) does not work, this is a bug with Herald itself, not with the Herald documentation.

Thanks for the report. This should be fixed in HEAD of master, and fixed in production some time in the next 24 hours when the docs regenerate.

Those changes add a fairly coarse disk-based cache here for use by the CLI. I expect it to shed ~95% of the load and make the admin tier stop glowing white-hot 24/7.

Follow PhabricatorSearchEngineExtension or similar.

(The second step is because some types of attachments work on multiple object types, and you could even conceivably write an "edge" attachment here that just works for anything and returns all edges, although I'm not confident that doing so isn't a major security problem.)

I think you've already written these, but the budget walkthrough is:

For the record, I strongly endorse autopatching unreviewed code onto live, armed, autonomous combat vehicles.

Internal attachment is definitely the shortest path. Whatever we end up with is likely to look very similar to the naive version, and you can keep your attachment running after we offer an "edges" attachment, so there shouldn't be any real transition cost.

This is basically a special case of T5873.

If you give a Phurl an "Alias", you can type ((thatalias)) in Remarkup to reference it. For example:

I added a note about this to T7338 for the longer term.

That should really have been in a day 1 "spend 10 minutes doing this stuff first" document, I started collecting this stuff in T11561.

Alternate/simpler test is "does /phurl/ work".

Also, are prototype applications enabled (phabricator.show-prototypes)? If not, Phurl won't actually be installed.

Ah, okay. I'm not immediately sure, then -- did you restart Apache / is /config/edit/phurl.short-uri/ picking up the change?

I suppose we could link to /config/module/site/, which has a list of all Sites, but it's probably not intuitively obvious from there what's going on. It's also possible in some future world to reach this screen without running Phabricator at all (T1806), although probably unlikely.

First screen is good.

I've updated both hosts and manually fixed D16464 to display the correct changes.

Yeah, I just neglected to push secure002 when I pushed secure001. I'll fix this shortly.

Oh, this looks like a smoking gun:

There's no changeset in the database, so this isn't just a weird permissions issue -- legitimately, no changeset was extracted.

bin/differential extract rPHU491ebc74d816dbe2fc8bbbbc992e8a14f8c613be also extracts the change correctly:

This might actually something more narrowly scoped since, e.g., D16468, D16469, and D16470 worked fine.

Ah, yeah. If you're using Apache with <VirtualHost /> directives, try something like this?

I think it's just adding implements PhabricatorApplicationTransactionInterface, then adding the methods for that.

Also to fix.

I think this is straightforward to fi.

Sorry, we don't offer help with third-party application development!

Probably not. Because it's a scalability issue this does get some amount of internal priority, but we have a large amount of external prioritized work in queue ahead of it (see Prioritized).

Not yet, but soon. New code should use project.edit.

T10423 was resolved indirectly (in connection with T11524) so we've sort of inched forward here.

Try using project.edit instead.

I'd like to sort out T9365 / T10635 (better aggregation and/or query options for unit/coverage data) first, since that likely impacts how we GC this data. Ideally, we'd leave an aggregated stub behind (e.g., pass/failure count) rather than nuking the data completely.

Specifically, my plan here is:

We can build this first, then backport it to Doorkeeper and feed.http-hooks, so this doesn't need to be an enormous mess.

If we just added an action to Herald like Queue Call to Webhook: http://whatever.derp/, would that cover this? I think that's often kind-of-a-bit-hacky, but probably makes a lot of these soft use cases easier.

I'm a little wary about this. Some of my concerns:

I think this is all generally reasonable to bring upstream, at least in spirit, but I want to wait for planned arc changes (overviewed in T11429) to get a little further along and build it on top of that.

I think you should already be able to add subscribers and projects (and take some other actions) with Herald, by writing a "Global" rule using the "Receiving email address" condition. Here's an example:

What do you mean that stuff? normalizeInput?