Hacker News Reader

Comment by egeozcan | Hacker News Reader

This seems to be built on an open-souce PHP->CLR compiler called Peachpie[1]. Interesting project. I don't have any PHP codebase that I still maintain but looking forward to trying it with some scripts I've written back in the days. I wonder if it would be faster than PHP 7 - which is already very fast (ok, just found these: http://www.peachpie.io/benchmarks ).

[1]: http://www.peachpie.io/

[edit] If the author is looking, a few nitpicks from the website:

- A blank page is shown if browser doesn't load 3rd party scripts by default

- After enabling them, the scroll wheel doesn't work

- Typo: "free completely to use" -> "completely free to use"

- "Run PHP apps on the most secure platform available, Microsoft .NET" -> I also admire the platform but most secure? Comes off a bit too strong.

View on HN

Just noticed a similar comment below - the openssl library which PHP is strugling with with every update. Peachpie uses the one in OS through the .NET being updated e.g. by Windows Update. So maybe "most secure" is too strong, but it is definitely more secure.

Never had any problems with PHP and openssl. Did I miss something or is this specific to the windows platform? (It's been a while since I updated PHP on a Windows system the last time).

Interesting. I had heard of https://github.com/DEVSENSE/Phalanger the predecessor to PeachPie.

>I also admire the platform but most secure? Comes off a bit too strong.

There aren't a lot of .NET exploits for a variety of reasons. Its pretty much the Java of the MS world so a lot of issues more liberal languages have, it doesn't, especially in regards to buffer overflows. Its attack surface is also pretty low as it only really inter-operates, by default, with a limited number of MS applications and is frequently the most common setup, while PHP supports anything and everything. Http.sys also seems like a more secure product than openssl.

That said, its also the minority platform so it benefits from a lack of effort to target it. I also worry that the closed nature of the platform could lead to someone(s) building up an army of zero days while the more open stuff gets discovered and disclosed faster. I'm not sure how realistic that fear is.

At my job we're always scrambling with our FOSS architecture in regards to emergency patching. The MS stuff is more or less 'do monthly patches and forget.'

> I also worry that the closed nature of the platform

.Net Core is 100% open source.

> Http.sys also seems like a more secure product than openssl

How is a goddamn HTTP parser in THE KERNEL more secure than a crypto/TLS library?

http.sys is a fundamentally horrendous idea, see CVE-2015-1635 https://technet.microsoft.com/library/security/MS15-034 An exploited HTTP parser shouldn't lead to RCE "in the context of the System account".

That's mostly client-side and easily avoided by not using IE/Edge. .NET uses its own library as well I believe. Not sure what the default is.

Historically, the schannel infrastructure has been secure, especially as compared to openssl.

>How is a goddamn HTTP parser in THE KERNEL more secure than a crypto/TLS library?

Because, lets face it, openssl is a shit project of legacy code no one wants to fix and https a design by committee standard no one can work well?

"an attacker would have to send a specially crafted HTTP request to the affected system"

"Disable IIS kernel caching"

That's definitely not client-side at all. IIS is the thing that uses http.sys, and classic ASP.NET apps (not the new Core stuff) are usually deployed with IIS.

The .NET Core example in the article uses the ASP.NET Core Kestrel server which operates entirely in user mode.

I know about Kestrel, I'm responding to that particular phrase in the comment :)

http.sys has ifdefs to support one platform, in one configuration. Meanwhile, https://mta.openssl.org/pipermail/openssl-dev/2015-January/0...

The number of config permutations in openssl is staggering, and that has to have an effect on the overall test coverage - which probably affects the number of bug that pass through testing.

Thanks for this, will fix asap.

Reply on news.ycombinator.com