In T11517#192337, @rayzyar wrote:

In T11517#192332, @michaeljs1990 wrote:

I've just tried to reproduce again, seems my steps cannot reproduce it.
I couldn't find out a good way to reproduce this bug.
Here is what I found :
when I change my existing code (removing the comment of an exported variable or method), arc lint at root git directory doesn't trigger the ADVICE
however arc lint xxx/xxx.go could trigger the lint ADVICE

And I tried to copy the same code to try to reproduce this, it works perfectly with arc lint at root git directory.
BTW, I am using some extension, https://github.com/zerodiff/traphic

Thank you a lot for looking into this

In T11517#192332, @michaeljs1990 wrote:

I've just tried to reproduce again, seems my steps cannot reproduce it.
I couldn't find out a good way to reproduce this bug.
Here is what I found :
when I change my existing code (removing the comment of an exported variable or method), arc lint at root git directory doesn't trigger the ADVICE
however arc lint xxx/xxx.go could trigger the lint ADVICE

You are going to have to post more information. I am able to correctly see the error you posted following these steps.

Can you post your arclint file

See Planning for timelines on how we work. If this issue is urgent and blocking your company, see Support Resources for prioritization options.

@chad could u take a look again

I put up a diff that fixes this however I'm not sure if it's the correct solution.

In T11535#191978, @epriestley wrote:

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

this is absolutely not a bug in libphutil it is with lighttpd. I will post a small example above showing you why.

This page was probably better. https://redmine.lighttpd.net/projects/1/wiki/docs_configuration#Troubleshooting

I'm still curious is this is a lighttp configuration issue. Ran across this comment from their documentation for example:

This didn't change the output. However, you can see I posted another solution.

Sorry, I missed the thread on this.

Okay, I think I'm into something. I logged the requests to see the differences between the one with curl command line that works, and the one from arcanist that fials.

Corrected the ip in the logs

Closing for now, feel free to follow up with steps we can follow to observe this locally. I have no idea how you're install got into this state.

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:

See https://github.com/tinfoil/devise-two-factor/issues/30 and https://github.com/mdp/rotp/issues/44 for some discussion about this issue (also discussed a bit on oss-security mailing list as http://www.openwall.com/lists/oss-security/2015/06/20/4).

I suspect that your computer is possessed.

Yes, I got that output:

Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 11.22.33.44...
* Connected to my.phabserver.com (11.22.33.44) port 8080 (#0)
> POST /api/conduit.ping HTTP/1.1
> Host: my.phabserver.com:8080
> User-Agent: curl/7.50.1
> Accept: */*
> Content-Length: 35
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 35 out of 35 bytes
< HTTP/1.1 200 OK
< X-Powered-By: PHP/5.6.25
< Set-Cookie: phsid=A%2Fx3d7s2ghnuyafelgkpilokjdmu3lw2rxvnkwcpcm; expires=Thu, 26-Aug-2021 04:37:41 GMT; Max-Age=157680000; path=/; domain=my.phabserver.com; httponly
< X-Frame-Options: Deny
< Content-Type: application/json
< Cache-Control: no-store
< Expires: Sat, 01 Jan 2000 00:00:00 GMT
< X-Content-Type-Options: nosniff
< Content-Length: 61
< Date: Sat, 27 Aug 2016 04:37:41 GMT
< Server: lighttpd/1.4.41
< 
* Connection #0 to host my.phabserver.com left intact
{"result":"someserver","error_code":null,"error_info":null}

An even simpler script below, works now on my Fedora 24 server. Just make sure for your distribution, that the correct database (mysql/mariadb/etc.) service is edited, as well as the rest of the info.

no, HTTPSFuture also knows http; My dev instance is http://127.0.0.1:8080/api/, and it works fine.

I don't have https enabled on my phabricator instance. Could it be related to my problem?

for domain:

domain
string(15) "my.phabserver.com"

So far I have made the computer draw some circles:

The theme today is "Ancient Technology", so PHP fits right in!

Do you have any other repositories to try this on? Smaller ones, or some public repo from BitBucket?

This has happened about 2 months ago, so a lot of the damage has already happened. We had a listing somewhere about what to do, but I can't find it now, so I'll re-write it here for posterity:

This can cause a storm of commit mail when upgrading. If there are old tags which weren't imported at the time, when Phabricator is upgraded to a version containing D16129 it can fire off thousands of commit emails, flooding inboxes and making some folks grumpy at their Phabricator administrators.

Can you var_dump($core_future) at https://secure.phabricator.com/diffusion/PHU/browse/master/src/conduit/ConduitClient.php;5fd1af8b4f2b9631e2ceb06bd88d21f2416123c2$146 and $domain at https://secure.phabricator.com/diffusion/PHU/browse/master/src/future/http/HTTPSFuture.php;5fd1af8b4f2b9631e2ceb06bd88d21f2416123c2$175 ?

No, it's a DNS name from https://freedns.afraid.org/

This would be awesome.

do you happen to be using a dns name that you populated using your /etc/hosts file?

Thanks @chad, but it seems not good enough.

I still got the 404 error even with php 5.6. Here's my php -v output:

PHP 5.6.25 (cli) (built: Aug 26 2016 20:28:05) 
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

I even removed php7 from my machine.
I got exactly the same error as before...

We don't expect to officially look into supporting PHP7 until 7.1. We've gotten a number of random issues from it we hope to be resolved in that release.

This is my php -v output... Does it have to do with the fact that I run PHP 7? But even so, like you said, it worked on secure.

PHP 7.0.10 (cli) (built: Aug 21 2016 07:35:18) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies

It's on arch linux, fully updated from today. My server is arch linux too, but I installed PHP 5.6 on it.

I'm pretty stumped here; Server seems OK, and client seems OK. Maybe test a completely different computer?

Maybe run php -v from command line, what system is this? But then again it works to secure...

I tried a couple of things, it seems it fails when trying to ping the server. This line $conduit->callMethodSynchronous('conduit.ping', array()); will throw the error, even though it clearly worked with curl.

Thanks!

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).

I did, and it certainly seems to match up. I'm surprised it's so dramatic. I guess since it was working fine before, the sensible thing is probably to just wait for the credits to recover and go back to things on the t2 micro.

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.

My graph certainly seems to imply that this is the issue.

Okay, so var_dump($uri) shows me that:
string(32) "http://my.phabserver.com:8080/api/"

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

I tried the address http://my.phabricator.com:8080/api/conduit.connect and it returned me a json that look like this:
{"result":null,"error_code":"ERR-INVALID-USER","error_info":"The username you are attempting to authenticate with is not valid."}

I'd start maybe here:

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

I don't think, with my current configuration, the port 80 is not accessible (limitation from my ISP), so I highly doubt I went through the wrong port.

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