I'm abandoning this revision; with the advent of PHP 7.2 (and Phabricator's ongoing support for PHP 7.x, now), password_hash can now use the new "Argon2I" algorithm when given a proper $algo parameter. See [The password_hash entry on php.net](http://php.net/manual/en/function.password-hash.php#refsect1-function.password-hash-description). From the PHP/admin side, this integration will be easier to use and install for Phabricator admins/maintainers (your distro/package manager will probably enable it for you) -- and from the Phabricator side, the code will be dramatically simpler and easier to reason about than this integration (e.g. no need to manually serialize parameters and validate them.)

Just as a side note: PHP 7.1.2 was released like a week ago, and I have not seen any more spurious segfaults on my instances when doing imports or anything like that on the server. The arc liberate bug remains dead and I have not seen any more faults in arc either. Builds should now be available in most PHP 7.1 repositories (in multiple distros/systems), so I suggest an upgrade for anyone who's affected.

i'm bad at search

Even better. Oh, and in my latest test just to make sure nothing horribly broke, Google even asked me to click some pictures and select street signs. My robot nature has been determined.

• remove unneeded phutil_implode_html

Ah, I see. Yeah, resolvex basically has the exact semantics I wanted anyway (checking the error code). I'll fix the $tags thing right quick and land.

Yeah, 7.1.2 RC1 seems to fix the problems. There are like 2 dozen random "uuhh fix off by one error, revert thing that overflowed something, you bastard, fix this too" commits in that commit log, even some affecting stuff like libgd (which you'd think would have been pretty hardened), so it's really impossible to tell what fixed what without it becoming tedious.

These are all done now - minor note, I wanted resolvex, not resolveJSON, which only exists (oddly) in ExecFuture and a few other places?

• mark recaptcha config options as locked in the UI
• fix a well-aged self-admin-XSS in emitting recaptcha tags
• use resolvex to handle non-200 status codes in HTTPSFuture
• clean up some tiny dead code

In T12196#210013, @epriestley wrote:

PHP7.1 segfaults about a dozen times a day for me, every day, with little apparent rhyme or reason to the segfaults.

I can only assume I am being punished for not rushing it into production as soon as possible. Perhaps we can deploy PHP 7.2 to production directly from master without waiting for an actual release.

Here's what the new UI looks like, when Recaptcha is configured on a newly created server. So much cleaner! (Especially on my HiDPI screen where the jaggedness of the old element was really obvious):

Awwwww yissssssss, looks like PHP 7.1.2 RC1 fixes it! Using the Fedora 25 "PHP 7.1 Remi Testing" repository, 7.1.2 just completely finished a run of arc liberate on Phabricator without problem.

Yeah, the sury repository is the one maintained by one of the PHP devs. I think if you just do something like apt remove php71* or apt remove php7.1* you can just reinstall all the php5.6 packages and you'll be dandy, at least as far as arc is concerned. They're all in the same repo, just separated by version suffix.

Just curious -- did you just notice this, or did you upgrade just to test this bug? If it was the first, that's an interesting data point! (that arc liberate is less common than I expected)

a devastating self-own. we've all owned ourselves.

Yup, that's the one @chad. I haven't tracked it down any further with strace or anything -- but if you try running that phutil_symbols.php command a billion times, note it doesn't fail every time, or possibly even at all (try like, for x in $(seq 1 1000); do php ... >/dev/null; echo $?; done | grep 1 or something). But if you run arc liberate again, it *will* fail every time, just on a different file, at a different point.

xhprof isn't needed to reproduce this; it's xhpast that's involved. Maybe. (xhpast is just a simple bison/flex parser/lexer combo so it isn't dependent on PHP internals in any way, and it's what drives the module parsing, etc)

i like that dog's hat. it's a good hat.

Ah, cool -- thanks!

In D17049#202017, @epriestley wrote:

is ur dev machine an original gameboy that you underclocked

FWIW, PHP 7.1.0 RC1 was released today, and it includes the async signal change. The following amended script from T11270#184087 seems to work:

Just as a note: I had this happen again on another very low-power instance (same file storage backend, encryption enabled etc), but with the latest HEAD, simply reloading with Ctrl+R after the webserver timed out the request made it continue and work perfectly. So yes, this is fixed it seems.

Thanks for listening to my hair-brained schemes. Yeah, the motivation is totally clear to me FWIW, and thinking about it more, I strongly suggest this is related to T9161.

In T10203#185476, @hach-que wrote:

Though it's worth pointing out CircleCI only supports 2 concurrent jobs at their highest tier, and 1 concurrent job for every other plan, so it's not suitable for a wide variety of purposes.

In T11307#185338, @epriestley wrote:

T10907 is also sort of adjacent.

I just wanted to add a vote of support for this (following up from here) - for Haskell.org Windows is one of the "Tier-1" platforms that we ship binaries for, and having continuous integration is exceedingly useful for a number of reasons.

Yeah, T8124 is definitely the error user-facing I saw when this occurred, except there's no possible way to edit your profile pic at that point as the exception takes up the whole page.

What I found interesting about this bug is, I've had some obvious high latency with this storage engine - but incremental storage uploads for large files work fantastic in every use case I've tried, e.g. cancelling requests and all kinds of stuff. I guess this 'magical' default profile picture creation can't use the 'resume upload' mechanics?

I updated my original answer (since I can't post a new one; I meant to add it as a comment on your original Q) with instructions on how to write the Herald rule you need, so you can accept that answer as "the accepted answer" for this Ponder.

In T8787#177689, @siepkes wrote:

My 2 cents; I wouldn't spent too much time on implementing various authentication schemes for Phabricator like Yubikey, U2F, password with SMS or whatever flavour of authentication comes out tomorrow. Since Phabricator supports OpenID such authentication schemes can easily be delegated to IAM solutions like GLUU, OpenAM, KeyCloak, etc.

Now it might be a good idea to make a tutorial showing how to install KeyCloak with Phabricator to get U2F support but actually trying to be an IAM seems like a waste of time and duplication of effort.

In T5000#176361, @thoughtpolice wrote:

The expectation is basically, "I want to contribute a typofix, and maybe some more later, but why I do I have to spend 20 extra minutes up front on my first patch, a typofix? Can't this be easier up front?" Note that GHC is a compiler so it inherently has a somewhat high activation energy; this is 20 minutes spent on top of the 20-40 minutes you spent already getting it to build, etc.

So in the case of Haskell.org, specifically the Glasgow Haskell Compiler (which I'll go ahead and put out there, since I believe we're the one who got this put on 'The Queue' in question), our root problem that we think this fixes, I believe, is not "Phabricator should act like GitHub" or "Phabricator should act like Gerrit", which aren't reasonable or actionable as requests. They're sometimes brought up, but not our real problem. Rather, it is "Contributing smaller changes carries lots of unnecessary friction, perhaps even psychologically, because of arcanist".