Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upcoming Hardening in PHP

dustri.org

Post reply on HN
Print view View original

91–100 of 130 posts

Re: Upcoming Hardening in PHP

#91

Post by mgkimsal »

ChrisMarshallNY wrote: post #55
ipaddr wrote: post #18

Earlier quoted context omitted.

Historically they have been one of the languages that added very few breaking changes and were criticized for that. You can't have it both ways. Going from php 4 to php 8 isn't even that painful and there are twenty years between. It's the one language where what you wrote 20 years ago probably still works today. Upgrading a php application is one of the least expensive and uneventful things you can do. Try upgrading…

There’s a system that I started working on, in 2008, when a lot of hosting outfits were still running PHP 4. It’s still running now, but I think one of the current maintainers rewrote a lot of it with Laravel, recently. I know that they were still using the old code, just a year or so ago, on PHP 8.

I had code I wrote for someone in 2002 (php4) still running in 2017 (php 5.x). It broke trying to go to 7, and it was a small area that broke. It was core, so broke everything, but it had to do with re-assigning of $this at runtime. I think in 5 it was complaining about it as a warning, but no one was looking. Had I/we been stricter about the use of $this back in 2002, that code might still be running today. Doesn't mean it should or wouldn't be faster if rewritten with newer language features, but ... it had a good run for 15 years.

EDIT: Was reminded of another site started in 2000 (start of PHP4) that is still running. I can only see the login page now, but I see the login page is still displaying a particular URL structure that was/is slightly uncommon. If they kept that but rewrote the entire thing internally... that would be odd, because it would be easier to rewrite the whole thing. I've no doubt they've upgraded some internal parts, if only to accomodate new business needs over the past 20+ years (I stopped working with this project in 2003?) but it's still up and running.

Re: Upcoming Hardening in PHP

#92

Post by Dachande663 »

phplovesong wrote: post #85
PaulRobinson wrote: post #48

Earlier quoted context omitted.

Python is slower than most of the horses I bet on. That's pretty slow. The important - CPU intensive parts - of numpy, pandas, pytorch, and all the other "fast python" libraries out there, are actually written in C. Pure python should not be used for anything that requires good performance: it is programmer ergonomic, not CPU ergonomic. It is great that through the use of FFIs it has access to powerful libraries writ…

Thats my point, pyton the is one of the slowest languages, and still have high quality, high perf libraries like numpy. PHP has no way to install deps that actually are written in asm/fortran or c.

PHP still has PECL[0] which is a huge collection of C extensions.

[0] https://pecl.php.net/

Re: Upcoming Hardening in PHP

#93

Post by johnisgood »

phplovesong wrote: post #86
chippiewill wrote: post #42

Earlier quoted context omitted.

Actually PHP itself is very fast compared to Python, especially for an interpreted language. Python only seems fast because all the heavy duty number crunching libraries are actually written in C.

Yet, just a pip install away. In PHP this is not possible.

Just a composer require away.

Re: Upcoming Hardening in PHP

#94

Post by calvinmorrison »

PaulRobinson wrote: post #45
ChrisMarshallNY wrote: post #2

> I find it fascinating that people are putting so much efforts optimizing exploitation techniques, yet ~nobody bothers fixing them, even if it only takes a couple of lines of code and 20 minutes. There's definite reward in having a 0-day. Either you can get a bounty, or sell it in the hacker-souk. That "couple of lines of code and 20 minutes" is sort of in the eye of the beholder. If you are a highly-experienced lan…

I think if somebody wants to describe themselves as an "ethical hacker", and a conference wants to let people talk about exploits they've found, the minimum bar for disclosure is at least a description of a mitigation that could be taken, and ideally an actual code diff if its an open source project. There's a bit of street cred for finding a 0day, a bit of glamour about figuring out the puzzle. There's not much for…

Selling hacks is ethical

Re: Upcoming Hardening in PHP

#95

Post by nucleardog »

phplovesong wrote: post #86
chippiewill wrote: post #42

Earlier quoted context omitted.

Actually PHP itself is very fast compared to Python, especially for an interpreted language. Python only seems fast because all the heavy duty number crunching libraries are actually written in C.

Yet, just a pip install away. In PHP this is not possible.

http://pecl.php.net/packages.php

`pecl install Tensor`?

Re: Upcoming Hardening in PHP

#96

Post by [deleted] »

phplovesong wrote: post #86
chippiewill wrote: post #42

Earlier quoted context omitted.

Actually PHP itself is very fast compared to Python, especially for an interpreted language. Python only seems fast because all the heavy duty number crunching libraries are actually written in C.

Yet, just a pip install away. In PHP this is not possible.

[deleted]

Re: Upcoming Hardening in PHP

#97

Post by mgkimsal »

ipaddr wrote: post #18
that_guy_iain wrote: post #15

Earlier quoted context omitted.

Honestly, the development of the PHP core has always been rather amateur. From historically just adding features whenever to know adding hundreds of breaking changes per minor release. This results in a terrible codebase and a language where upgrading minor versions is so painful and costly for some firms they end up stuck on old version. The last part makes the fact their could be massive security holes like RCE in…

Historically they have been one of the languages that added very few breaking changes and were criticized for that. You can't have it both ways. Going from php 4 to php 8 isn't even that painful and there are twenty years between. It's the one language where what you wrote 20 years ago probably still works today. Upgrading a php application is one of the least expensive and uneventful things you can do. Try upgrading…

Somewhat contrary to my own comment below, migrating PHP upwards can be painful, but some of that stems from who's involved. I'm brought in on PHP upgrade projects, and often the code is 10+ years old, and no one who wrote it is still around. There's typically no documentation, no tests, and little historical knowledge.

Now... that's also a problem in other languages too, but I've found it less so with something like... older Java. Because there are some things that are completely gone from earlier PHP, if people relied on those bits 15 years ago, there's potentially a lot of code touching that needs to happen.

My experience is there's less deprecation of language features in older languages (mostly thinking of Java). There were perhaps less 'wonky' ways of doing dynamic Java stuff in 2006, so 2006 Java will still work today. 2006 PHP can work today (see comments below), but the more 'advanced' your PHP was the more at-risk it will be when trying to upgrade to, say, PHP 8.x.

The other big thing, though, is frameworks. The more you tied your code to, say, ZF1, the bigger an upgrade effort will be (sometimes far bigger than expected). I've been hit by this a couple times in the last few years.

Re: Upcoming Hardening in PHP

#98

Post by justinclift »

bigtimesink wrote: post #23
justinclift wrote: post #6

> Suggestion to make those parts read-only was rejected as a 0.6% performance impact was deemed too expensive for too little gain. Big Oof. :( :( :(

At a large PHP shop, 0.6% can be tens of millions of dollars.

No doubt there. It's just that providing a secure platform seems a tad more important.

Re: Upcoming Hardening in PHP

#99

Post by bwoebi »

p4bl0 wrote: post #24

Something I'd really like is for PHP to somehow be stricter on the number of arguments passed to a function. As of now, PHP emits an error if arguments are missing but not if there are too many. A way to bake that in without breaking old code would be to allow function definition to put an explicit stop to the argument list, for example using the void type keyword: function foo (int $a, string $b, void) : bool { ...…

One of the main advantages of actually allowing more arguments is forward compatibility:

You can, within a library, provide an additional argument to a callback without actually introducing a BC break for all users.

My favorite approach would be allowing too many args on dynamic calls (closures, and function calls with dynamic name, not method calls in general) and otherwise rejecting it.

Re: Upcoming Hardening in PHP

#100

Post by arkh »

phplovesong wrote: post #85
PaulRobinson wrote: post #48

Earlier quoted context omitted.

Python is slower than most of the horses I bet on. That's pretty slow. The important - CPU intensive parts - of numpy, pandas, pytorch, and all the other "fast python" libraries out there, are actually written in C. Pure python should not be used for anything that requires good performance: it is programmer ergonomic, not CPU ergonomic. It is great that through the use of FFIs it has access to powerful libraries writ…

Thats my point, pyton the is one of the slowest languages, and still have high quality, high perf libraries like numpy. PHP has no way to install deps that actually are written in asm/fortran or c.

> PHP has no way to install deps that actually are written in asm/fortran or c.

https://www.php.net/manual/en/book.ffi.php is not enough for your needs?

Post reply on HN