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.

EditEngine is a slightly different way to build forms that look the same as other forms, introduced circa January 2016. Some applications have moved to it, while others have not yet. It seems pretty reasonable and stable, though, so we're in the process of moving everything over.

First, let's sort of limit the direct damage this misconfiguration causes by changing this line in PhabricatorUserLog->initializeNewLog():

T7643#175911 has some discussion of this.

Is there a valid technical reason for Google to work like this?

Ah, nice! I'll write up some guidance on adding a setup check for this shortly.

In the read/write case, it's too late once we hit a hook -- we need to be able to decide which cluster node to send the traffic to, and we need to know if it's a read or write request before we make that decision, since there may be a nearby read-only node and a distant read/write node. If we can examine the stream and make a determination that the request is read-only, we can freely pick a nearby read-only node.

Today, we technically do not need to decode the protocol, but we will need to be able to distinguish between read and write requests to implement cluster read-only nodes (T10883) in the future and need to be able to rewrite the protocol to keep parity with fork-like/virtual-ref features that we plan to support in Git (T10691, T8092).

The action is indistinguishable from an update from Herald's perspective. Herald runs on the state of the object, not changes to it, so "Changed file content" will just match whatever the diff changes.

No one actually seems confused by Paste. Obviously documentation "should" exist, but probably not worth keeping this task around since it has just been idle for more than a year. I suspect we'll write it as soon as someone runs into a problem that needs to be documented.

We haven't seen more interest in this in a long time, and I don't currently plan to make compatibility-focused changes to the stack.

I'm going to merge this into T10448, which discusses limitations and improvements to the mail tags system. This is an example of a cross-cutting tag ("No Application/System Settings") that isn't handled gracefully by the current system, but correcting this and other similar issues is a goal of future work.