Presuming resolved.

Can you make a single call to some kind of middleware which looks up the token based on the callsign or ID, then submits the request to the build server?

You can parameterize the URL, in a build step, e.g.:

What kind of rules are you duplicating across repositories? Why can't these rules be expressed as a single rule which affects all the repositories?

We may also be vulnerable to the parse_url() vs cURL parsing issues that SafeCurl encountered, however.

We may also be vulnerable to the parse_url() vs cURL parsing issues that SafeCurl encountered, however.

It doesn't, it hits the same dilemma and elects to disable SSL verification. See:

D12151 protects against redirection attacks for in-process requests.

PhabricatorApplicationTransactionView sits on top of PHUITimelineView. It just builds/configures a TimelineView when rendered.

PhabricatorApplicationTransactionView? Used in every application, I think.

No.

I'm starting to think this is expected. I can get used to it, but my initial reaction was "this looks weird and broken".

Package files are generated on the fly. There are no generator logs.

Your configuration is significantly different from the recommended configuration in the documentation:

We use nginx on this server and the same resource loads properly:

I've removed the two major sources of needless/expensive highlighting (D12132, D12141). There's a third that will eventually be resolved by T5501 (roughly, if APC settings are whack you'll run setup checks on every page, including setup checks against pygmentize).

Enabling OpenSSL is trivial and Filesystem::readRandomBytes() is used to generate cryptographically sensitive randomness.

We haven't seen other interest in this kind of configuration, so we'd prefer not to maintain documentation about it. Feel free to publish a blog post or whatever, though. Glad to hear things are working now, let us know if you run into anything else.

For example, suppose your proxy has IP 1.1.1.1 and your application server has IP 2.2.2.2. The flow of the request should be:

You should configure the reverse proxy to connect to the underlying host without mutating the "Host" header of the request (this should be the default behavior of most reverse proxies, so I'm surprised it isn't the configured behavior).

You should simply replace all references to phabricator.int.domain.com with phabricator.domain.com, and forget that phabricator.int.domain.com exists.

Are you trying to serve Phabricator on two different URIs? For example, so non-VPN'd users connect to phab.domain.com and VPN'd user connect to phabricator.int.domain.com?

If we ran linters, we'd end up catching this syntax error in about 5 seconds.

Can you walk me through your use case in more detail? We've never seen interest in this, and I can't come up with reasons why this would be useful offhand.

The major issue is that this isn't scalable. If your lint+unit tests take 2m to run, the target branch is limited to 30 commits/hour. If you try to commit faster than that, you'll get a clean result and then try to push, but it won't be a fast-forward since someone beat you. And a naive implementation means there's no queueing, so it might take you an arbitrarily long time to actually get your change in, and you have to babysit it the whole time.

Or "free", at least. Where would you group "joinable by specific users", "joinable by users not in project Y", "joinable by members of external LDAP group Q", "joinable when the moon is full", etc., though?

Yes, that's free. It's the query we issue in every application when showing a list of tasks, revisions, etc.

although I think this may only stop the data retrieval version of the attack

Remaining work here is:

I personally think the behavior as-implemented is correct/desirable. We could change this, but it's a lot of work and I think it's worse from a product perspective. For example, I think this is bad/undesirable:

Or, in particular, a clarification of this:

Outcome: People in Phacility or Wikimedia projects automatically have this Room in Conpherence.
Outcome: The Photos projects members automatically have this Room in Conpherence.

Presuming this is resolved.

ops woo~~

I also think linking to the specific transactions makes sense in HTML mail since we have space to stick it somewhere subtle (see, e.g., T6600 and blocking tasks) but it feels low-value to me in plain-text mail, if we assume we start generating higher-quality text diffs.

The HOME environmental variable is also getting wiped out, so we don't know where to find ~/.arcrc, which contains the credentials you installed.

SVN wipes the environment, so my guess is that arc is no longer in PATH. You could try redirecting stderr as well to see the issue:

I'd like to put the diff itself in the email, but the diffs are of very low quality until T3353.

not sure if there is a technical reason not to.

This was fixed by D12007.

I don't think there's anything reasonable we can do here.

Gluing two providers together in this way is not a use case we're interested in supporting in the upstream.

No, it appears that we can remove the flush() call with no general loss of functionality.

We use nginx here, but Apache in the Phacility cluster and I use Apache locally, and I can't reproduce in either of those environments.

Okay. There are two relevant parts in that diff, both in src/aphront/sink/AphrontPHPHTTPSink.php:

Try reverting rP81d8898 with:

Sadly, not today.