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?

I had some family stuff come up and was only able to spend about three hours on this before Ludum Dare ended, and it never turned into anything playable. I got as far as letting you jump between systems and zoom into planetary bodies:

This is almost certainly T4369. I would expect that this repository is larger than 2GB?

Basically, if you want to see this implemented, please describe an attack scenario you're concerned about in detail.

Yes, I wasn't aware that enable_post_data_reading existed when I wrote this.

This is technically easy for us to implement, I'd just like a real security justification for it. From the first link, the justification seems to be:

So far I have made the computer draw some circles:

I'll retarget this to add a setup warning about micro instances, this isn't the first time they've done surprising things (T2727, T8204, T8210).

If you fiddle with the dropdown in the upper right you should be able to get historic data and maybe see if the graph went not-so-good around then. Doesn't seem implausible.

If the task is frequently referenced, you can give it a Phurl and use ((super_cool_task)), as in ((php7)) and ((httpoxy)).

Here's the actual credit graph in the AWS web console, under the Monitoring tab (lower right):

One thing we could possibly do is try to hit the AWS meta-service during startup:

It's hard to say because workloads differ, but I'd steer away from the CPU credited "burstable" t2.* instances based on generally negative experiences with micros in the past.

In AWS, my understanding is that micro instances have CPU credits and their CPU is stopped or heavily throttled if you exceed the credit hours. Has the instance exhausted its CPU credits? I think there's a graph on the console, maybe in the "CloudWatch" tab or something like that? I don't actually have any micro instances up right now to check.

(Is your server an underclocked Raspberry Pi emulated on an Amiga?)

Does /usr/bin/env php -v also print 5.6, versus 7?

See some discussion in T3945.

D16460 is marked as fixing this, and we always send data via Files afterwards. This is different from the approach I'd outlined above (no mode where we continue to return text directly), but two additional considerations have arisen:

Yes, that's correct.

Oh! var_dump(...) or print_r(...) should send stuff to a big pink header on the page.

Ah, right -- I think those are both expected and that you're on the right track. You should be able to use $request->getStrList(...) instead of $request->getStr(...) to read the list, then head() to grab the first (item if it exists).

I'm happy to rewrite your script so it works, but we charge $1,500/hr for custom development (see Consulting) because time spent helping individual users with unique problems takes away from developing and improving Phabricator. Are you interested in this?

This is not a bug.

Introducing an epoch64 type ends up being pretty messy:

Perhaps a better solution is to introduce an epoch64 datatype and store these timestamps faithfully, since they're at least sort of possible to write and do have a relatively unambiguous meaning. Introducing a new type instead of changing the meaning of the existing epoch would let us accommodate this without requiring tons and tons of migrations or exposing us to a lot of weird fallout.

After some effort, I'm unable to figure out how to generate these commits using vanilla git. I can't figure out how get them with --date or GIT_COMMITTER_DATE to git commit: dates after 2100 are treated like the current date.

Why are you tracking branches you don't want to land onto?

The particular issue is that that the change removed a file containing the bytes ... 0xE5 0x76 .... The 0xE5 is probably an å in Latin 1.

I extracted the response body prior to encoding as a serialized()'d object so I can narrow down what's causing the encoding to fail and it looks reasonable, looking like it's almost certainly a UTF8 issue now.

Not too surprisingly, the response is empty. AphrontResponse->encodeJSONForHTTPResponse() uses json_encode() and does not detect UTF8-related encoding failures, so the chance that this is a UTF8 issue is pretty high. We should also probably fix that so fail earlier and more explicitly (and don't emit HTTP 200).

The next step I want to take is figuring out what the actual problematic response body looks like, but that's slightly tricky right now because there's no way to make Conduit calls from the CLI.

I want to avoid implementing things in Phabricator just because there's a low barrier to entry to ask us and we're responsive -- over time, this tends to punish us for being responsive by cluttering our codebase with cruft to work around weird decisions that other companies are making in their products.

From IRC, this might be a false positive / not the root cause since destroying the binding didn't fix the problem, but I can run through things locally.

I was ultimately able to reproduce this, but it took some work and the instructions above definitely weren't sufficeient:

Alright, let me see if I can get anywhere with this.

Phurl is a URL shortener. This is an amazing unique type of application which I personally invented in 2015.

I've also never used seamless so I'm not sure how support looks in practice, but this isn't immediately reassuring:

I think that only prevents referrer leaking -- it doesn't deal with the other issues in T4190#60441 (or request amplification attacks), right?

The vaguely related T5378 is also in the queue somewhere. It may not really intersect with this, but if we do end up trying to auto-embed any URI that ends in .jpg again it probably will. I'm not sure we should, but just a heads up for context.

The general shape of what we're trying to do here is that when a user writes the URL of an image in a comment (e.g., http://funny.lol/silly-dog.jpg, perhaps with some magic *$!symbols$*!) it would be nice to just show the image. Today, they'd have to download and re-upload it, which is somewhat cumbersome.