Hi, On 09/19/2017 10:50 AM, C. Scott Ananian wrote: Migrating to Hack simply isn't feasible for most users of MediaWiki. Most distros don't have packages for HHVM, and it's not straightforward to build AIUI. Once you've figured that out, then you're going to quickly realize that you need a cron job to regularly restart HHVM because it'll OOM/crash/etc. So either you have downtime or multiple HHVM processes. On the MediaWiki development side, we've been forced for fork all of the external libraries we depend upon to support Hack. This includes basic tooling like composer, phpunit, codesniffer, and so on. There are probably more reasons that could be listed, but I think you get the idea of why Chad considers it to be a non-starter. -- Legoktm

Chad: thanks for writing up all of those in one place. I'm not actually trying to argue *for* Hack here. My argument is just that we should take the time to lay out the arguments carefully on both sides, since this is a decision that is likely to have long-lasting effects. Think of this like the traditional [[devil's advocate]] process for canonizing a saint. I'm just challenging us to take a hard look at our reasoning and make sure it is well-founded technically. In my ideal world we'd take your excellent point-by-point argument and try to rigorously quantify each, just to satisfy ourselves that we've done due diligence. You say "there's not much migration cost moving to PHP7" -- well, it would be nice to assign someone to go through the details in a little more detail to double-check that. "Various benchmarks dhow HHVM and PHP7 performance to be roughly on par" -- firmer numbers would be nice, as you say. I think Tim was already going to do this? "A bunch of major projects have already dropped HHVM" -- again, can we take the devil's advocate position and ask the HHVM team who *hasn't* dropped HHVM ;) and ask for their reasons? You also raise some points about packaging and portability that I could probably counter by pointing out that HHVM has an ARM and PowerPC JIT now ( http://hhvm.com/blog/2017/03/09/how-the-cyber-elephant-got-his-arm.html), while Zend's JIT-in-progress only supports x86. We could also poke at the HHVM folks and ask about their packaging plans, since they (according to their announcement) are going to "reinvest in open source". You also mentioned PHP's long history of FLOSS without also mentioning their long history at sucking at security. And we could try to quantify how dependent PHP is on Zend contributions vs how dependent HHVM is on facebook contributions. We can get numbers on this, we don't have to assume things. The HHVM announcement specifically mentioned that they will maintain compatibility with composer and phpunit, so that seems to be a wash. The references/destructors thing is actually really interesting as a technical discussion. The reason given for removing these is all about performance, in particular the performance hit you get from ref-counting as opposed to pure GC. There's been a lot of really good GC work done in the past two decades; see https://news.ycombinator.com/item?id=11759762 although I like to cite https://www.cs.princeton.edu/~appel/papers/45.ps as foundational. It may be a good opportunity to take a hard look at our Hooks system and figure out if its design is future-proof. --scott On Tue, Sep 19, 2017 at 2:04 PM, Chad <innocentkiller(a)gmail.com> wrote: -- (http://cscott.net)

Hi! OK, so it's a big topic but I can do some quick survey and we can get deeper if you want to. So: Despite what you see there, there are not a lot of genuine security issues in PHP. Unfortunately, CVE issuance process is such that it does not involve any consultation with the vendor about classifying the issue and assigning severity. You can just create CVE ID for anything and how they assign severity is kinda mystery to me, but one thing is clear - PHP core team is not consulted about it, at least not in any way I've ever noticed. It doesn't mean those are all wrong, but some probably are, and a lot are misclassified. Now, for the substance of the issues. Many of them are unserialize() issues. For this, without getting too much into the woods, I can only say this: there seems to be no way to make unserialize() robust against untrusted data, and it has to do with how references, object construction, object destruction (notice the similarity with what Hack intends to drop? It is not a coincidence) and serialization support works in PHP. There is too much internal structure exposed to make it work with untrusted data now. Maybe if we redesigned the whole thing from scratch, it _could_ be possible, but even then I kinda doubt it, at least not without sacrificing some feature support. For now, the best approach to this is consider using any unserialize() on untrusted data inherently insecure. It's just too low-level to be sure no corner case ever does anything strange. Some of those are genuine security problems, which now mostly concentrate in several extensions, which has been either under-served or have very wide exposed areas. Namely, wddx - obscure format that suffers from issues similar to unserialize() and in addition lack maintainership, phar - which wasn't really designed to deal with untrusted scripts but seem to kinda be moving that direction, and gd - which mostly relies on libgd and every issue there is also automatically extends into PHP. The latest two would probably benefit from a good fuzzing testing, but nobody took on it yet. I suspect if hhvm uses the same or derived code - and it likely does, I don't think they reimplemented libgd from scratch? - many of those would also be present in hhvm if hhvm supports these (no idea). There are also some long-standing debates about how randomness is handled (basically, there are many ways to get randoms, and most of them are not suitable for security-related randomness) and some DoS issues in PHP hash tables - the latter are mostly resolved, but in kinda temporary way, so there's more work to be done. Some of these issues - like https://bugs.php.net/bug.php?id=74310 - are definitely not security issues at all. Yes, you can create bad code that hits some corner case and produces segfault. That shouldn't happen, but this being complex C code which is 20 years old, it does. This has absolutely nothing to do with security, and whoever decided to issue CVE to it and assign 7.5 severity (https://www.cvedetails.com/cve/CVE-2017-9119/) has done a very sloppy job. As I said, this is done with zero communication with actual PHP team as far as I know, which is very sad, but this is the state of affairs. Some of those are, I am sorry to say, complete baloney, e.g. https://www.cvedetails.com/cve/CVE-2017-8923/ says: <<The zend_string_extend function in Zend/zend_string.h in PHP through 7.1.5 does not prevent changes to string objects that result in a negative length, which allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact by leveraging a script's use of .= with a long string.>> This is nonsense - unless you run with no memory limit at all (nobody sane does that) and specifically allow your code not only accept infinite untrusted data, but have it fed specifically to certain functions arranged into a specific code pattern, no remote attacker can do it. There are many issues that have similar claims, none of them are actual security issues. Some are also assigned to PHP despite them being application issues, e.g. https://www.cvedetails.com/cve/CVE-2017-9067/. To add insult to injury, this is 2017 CVE about a version that was EOLed in 2014. The data quality seems to be very sad there. I tried to figure out how to make it better a while ago but pretty much gave up on it because I couldn't find anybody responsible or at least concerned about this sad state of things. OK, this came out super-long and kinda ranty (sorry!), so I will stop for now, but if you have any questions about it, please feel free to ping me, and I will be glad to discuss it. -- Stas Malyshev smalyshev(a)wikimedia.org

בתאריך 19 בספט׳ 2017 22:52,‏ "Kevin Smith" &lt;ksmith(a)wikimedia.org&gt; כתב: On Tue, Sep 19, 2017 at 11:41 AM, C. Scott Ananian &lt;cananian(a)wikimedia.org&gt; wrote: ​I for one appreciate your engagement here, even if it has not been popular. +1 Rejecting HHVM and Hack may seem obvious to many people, but not to everybody.