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

81–90 of 130 posts

Re: Upcoming Hardening in PHP

#81

Post by Kwpolska »

larsnystrom wrote: post #46
phplovesong wrote: post #41

Earlier quoted context omitted.

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 :)

Python is also written in C.

Re: Upcoming Hardening in PHP

#82

Post by 1oooqooq »

metadat wrote: post #5

The linked CVE-2024-2961 article is a pretty fantastic read on its own: https://www.ambionics.io/blog/iconv-cve-2024-2961-p1 People are so creative, I can't help but feel some hope for our future :)

i find it boring. because it's very obvious whoever added php://filter was clearly just adding exploit paths (java flavored ones no less). there's zero valid use for that thing.

Re: Upcoming Hardening in PHP

#83

Post by acomjean »

cess11 wrote: post #71
phplovesong wrote: post #41

Earlier quoted context omitted.

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.

PHP has decent FFI, nothing is stopping you from using the same libraries as you would with Python. Here's someone's quick hack as an example: https://github.com/dstogov/php-tensorflow For an interpreted language PHP itself is ridiculously fast and the VM is rather small so you can use something else cough Elixir cough for parallellisation. I use it all the time for data wrangling stuff and database imports because i…

PsySh

I’ll have to check this out.

Though not popular php can be a surprising decent scripting langauge.

Re: Upcoming Hardening in PHP

#84

Post by 1oooqooq »

Tepix wrote: post #62
bigtimesink wrote: post #23

Earlier quoted context omitted.

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

At a large PHP shop, a successful exploit can be the end of the company.

almost everyone have all the things required for those exploits disabled.

why would i accept performance penalty if i don't allow open('https://google.com') to begin with?

the correct action would be to remove all the stupid features everyone serious disable to begin with.

Re: Upcoming Hardening in PHP

#85

Post by phplovesong »

PaulRobinson wrote: post #48
phplovesong wrote: post #41

Earlier quoted context omitted.

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

Re: Upcoming Hardening in PHP

#86

Post by phplovesong »

chippiewill wrote: post #42
phplovesong wrote: post #41

Earlier quoted context omitted.

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.

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

Re: Upcoming Hardening in PHP

#87

Post by phplovesong »

larsnystrom wrote: post #46
phplovesong wrote: post #41

Earlier quoted context omitted.

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 :)

Its not wrong, numpy is a pyrhon package (written in c) but you can USE it just with an pip install.

Re: Upcoming Hardening in PHP

#88

Post by talkin »

withinboredom wrote: post #30
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 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…

To be specific about static analysis: Lots of tools catch this. Sure, making some checks native would be nice, but for instance PHPStan always catches this, and more.

Regardless of the ‘improve the language angle’: Is somebody isn’t running PHPStan (or Psalm, Sonar, etc), then they’re missing out.

PHPStan is currently so good that using it should be non-negiotable. So the question would then even be: “I’d like rule 123 of the tool to be native, we helps with the RFC?”

Re: Upcoming Hardening in PHP

#89

Post by talkin »

chippiewill wrote: post #42
phplovesong wrote: post #41

Earlier quoted context omitted.

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.

This comment and all siblings fight over PHP vs Pyhton etc, but that just isn’t the bottleneck in most apps.

By far, for most apps, the biggest bottleneck is the database.

Re: Upcoming Hardening in PHP

#90

Post by talkin »

1oooqooq wrote: post #82
metadat wrote: post #5

The linked CVE-2024-2961 article is a pretty fantastic read on its own: https://www.ambionics.io/blog/iconv-cve-2024-2961-p1 People are so creative, I can't help but feel some hope for our future :)

i find it boring. because it's very obvious whoever added php://filter was clearly just adding exploit paths (java flavored ones no less). there's zero valid use for that thing.

Yes. Just like the Log4j issue root cause. Too powerful and abstract features to wield securely.

Or maybe if we keep intent out of it; features were added in a time when we all worried less about security and internet implications. I would like to say ‘in the security dark ages’ but we are probably still in that era. ;)

Post reply on HN