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

41–50 of 130 posts

Re: Upcoming Hardening in PHP

#41

Post by phplovesong »

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. :( :( :(

PHP has always ben slow, its getting slightly faster, but still REALLY, REALLY slow for anything CPU heavy. This is why the ML crowd sticks with Python (numpy) thats incredibly fast.

PHP is still lacking, there is no unicode support, and for a web language this is really bad. Also, the way PHP functions, makes modern web (like websockets) use impossible, there is hacks around this but they all kind of suck.

Re: Upcoming Hardening in PHP

#42

Post by chippiewill »

phplovesong wrote: post #41
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. :( :( :(

PHP has always ben slow, its getting slightly faster, but still REALLY, REALLY slow for anything CPU heavy. This is why the ML crowd sticks with Python (numpy) thats incredibly fast. PHP is still lacking, there is no unicode support, and for a web language this is really bad. Also, the way PHP functions, makes modern web (like websockets) use impossible, there is hacks around this but they all kind of suck.

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.

Re: Upcoming Hardening in PHP

#43

Post by notresidenter »

p4bl0 wrote: post #35
withinboredom wrote: post #30

Earlier quoted context omitted.

I don’t really understand the issue. Already if you have a mismatch, the only way you’d ever know is through static analysis. It will run and maybe crash during run time. I always joke that changing a function signature is the single most risky thing you can do in php (especially if you have any dynamic dispatch). Making it even more risky isn’t the right answer, IMHO. Oh, and doing this would literally break class a…

> the only way you’d ever know is through static analysis Not for builtin PHP functions which already throw errors on arity mismatch. > this would literally break class autoloading in symfony, and even the engine itself, which relies on this feature I don't understand. Could you point to where in the Symfony code it relies on being able to wrongly call a function with more arguments than it expects and will use? For…

You should look at `func_get_args()` usage in the wild. This is sometimes used for (mostly outdated) good-enough reasons and doing this might break it?

Re: Upcoming Hardening in PHP

#44

Post by rkharsan64 »

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 { ...…

Somehow people seem to be missing the fact that this would've been an opt-in feature.

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

Re: Upcoming Hardening in PHP

#45

Post by PaulRobinson »

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 the person who fixes it. I think as an industry it might be worth trying to fix that somehow.

Re: Upcoming Hardening in PHP

#46

Post by larsnystrom »

phplovesong wrote: post #41
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. :( :( :(

PHP has always ben slow, its getting slightly faster, but still REALLY, REALLY slow for anything CPU heavy. This is why the ML crowd sticks with Python (numpy) thats incredibly fast. PHP is still lacking, there is no unicode support, and for a web language this is really bad. Also, the way PHP functions, makes modern web (like websockets) use impossible, there is hacks around this but they all kind of suck.

I'm pretty sure this is wrong. PHP has been faster than Python for a long time, but numpy is not written in Python, it's written in C. Just like PHP, coincidentally :)

Re: Upcoming Hardening in PHP

#47

Post by mklepaczewski »

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 { ...…

I'm not a fan of the void argument syntax. Wouldn't something like the code below work? We already do it with `strict_types=1`.

<?php declare(strict_args=1);

Re: Upcoming Hardening in PHP

#48

Post by PaulRobinson »

phplovesong wrote: post #41
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. :( :( :(

PHP has always ben slow, its getting slightly faster, but still REALLY, REALLY slow for anything CPU heavy. This is why the ML crowd sticks with Python (numpy) thats incredibly fast. PHP is still lacking, there is no unicode support, and for a web language this is really bad. Also, the way PHP functions, makes modern web (like websockets) use impossible, there is hacks around this but they all kind of suck.

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 written in a language that isn't slow, but that does not make it as a language itself, fast.

Re: Upcoming Hardening in PHP

#49

Post by pjmlp »

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…

When liability and cybersecurity laws start being more hardly enforced, many companies will certainly bother to fix them.

It like no one cares to keep a kitchen clean, or a factory in order, until the inspection shows up and closes doors.

Naturally even for those, we are at various levels of how those inspections are honestly enforced across the globe.

Re: Upcoming Hardening in PHP

#50

Post by 0points »

p4bl0 wrote: post #35
withinboredom wrote: post #30

Earlier quoted context omitted.

I don’t really understand the issue. Already if you have a mismatch, the only way you’d ever know is through static analysis. It will run and maybe crash during run time. I always joke that changing a function signature is the single most risky thing you can do in php (especially if you have any dynamic dispatch). Making it even more risky isn’t the right answer, IMHO. Oh, and doing this would literally break class a…

> the only way you’d ever know is through static analysis Not for builtin PHP functions which already throw errors on arity mismatch. > this would literally break class autoloading in symfony, and even the engine itself, which relies on this feature I don't understand. Could you point to where in the Symfony code it relies on being able to wrongly call a function with more arguments than it expects and will use? For…

IIRC, that's how symphony and other php frameworks do dependency injection.
Post reply on HN