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

31–40 of 130 posts

Re: Upcoming Hardening in PHP

#31

Post by reddalo »

MH15 wrote: post #28
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'd be curious to read about what percentage of active PHP devs use the recent features. The last time I worked in a PHP codebase (2020?) was half PHP 5 (bad) and half PHP 7 (much nicer). Curious if there's any real info out there on this

The Laravel ecosystem folks seem to be always up to date in recent PHP developments. At least, that's my impression.

Re: Upcoming Hardening in PHP

#32

Post by arkh »

that_guy_iain wrote: post #20
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…

My complaint was adding lots of breaking changes to minor version upgrades. The fact, that historically they didn’t do breaking changes in major version upgrades does not excuse going against industry standards. There are literally companies stuck on PHP 7 because going to 8 is too painful. And honestly with my decade of experience your claim that going from 4 to 8 isn’t that painful sounds like nonsense and somethin…

> There are literally companies stuck on PHP 7 because going to 8 is too painful.

Usually due to frameworks. Those tend to do play fast and loose with language constructs so small changes can make them not work anymore. And as those same framework will also break a lot more things between version, you cannot easily upgrade them, so you cannot upgrade your php version.

Currently maintaining an internal symfony 1 website so I know the pain. At least the documentation of old symfony is still available unlike many more modern frameworks.

Re: Upcoming Hardening in PHP

#33

Post by post_below »

MH15 wrote: post #28
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'd be curious to read about what percentage of active PHP devs use the recent features. The last time I worked in a PHP codebase (2020?) was half PHP 5 (bad) and half PHP 7 (much nicer). Curious if there's any real info out there on this

PHP 5 is as close to phased out as it gets at this point. No doubt it's still in a lot of legacy enterprise codebases (lots of breaking changes going from 5 to 7 or 8), but outside of that no one is using it.

Re: Upcoming Hardening in PHP

#34

Post by Cthulhu_ »

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

It might be too big a change on a language level given this has been in since forever, but it might be picked up by static analysis / a linter. I'd argue it's always better to have additional protections like this in a linter as the process of adding linter rules is easier and less impactful than making a language change.

It's also always preferred to not add anything to the language imo; in this case, I'd opt to have the interpreter emit a warning or info message. It's not broken, it's a developer error.

Re: Upcoming Hardening in PHP

#35

Post by p4bl0 »

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…

> 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 variadic functions there is the ... operator already in the language since version 5.6, and my proposal wouldn't break that. Also note that builtin functions already emit deprecated warning in PHP 8 when called with too many arguments.

Here is the full thread discussing it on the PHP internal mailing list: https://news-web.php.net/php.internals/122928

Re: Upcoming Hardening in PHP

#36

Post by naiv »

reddalo wrote: post #31
MH15 wrote: post #28

Earlier quoted context omitted.

I'd be curious to read about what percentage of active PHP devs use the recent features. The last time I worked in a PHP codebase (2020?) was half PHP 5 (bad) and half PHP 7 (much nicer). Curious if there's any real info out there on this

The Laravel ecosystem folks seem to be always up to date in recent PHP developments. At least, that's my impression.

Symfony also does a great job adding polyfills way ahead of a PHP release , eg https://github.com/symfony/polyfill-php84

Re: Upcoming Hardening in PHP

#38

Post by esskay »

that_guy_iain wrote: post #15
mgaunard wrote: post #3

The real question is why does PHP have so many bugs that it's so trivial to exploit?

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…

> From historically just adding features whenever to know adding hundreds of breaking changes per minor release.

Should be noted that it stopped being the case close to a decade ago now. Since PHP 8 things have changed a lot and it's a significantly better platform, both in terms of usage and the people behind it.

PHP spent a long time running on fumes with little backing. It's now got huge financial backing from Jetbrains, Wordpress Symfony, Laravel etc and theres now people paid to work on it, which has dramaticly improved the quality and quantity of improvements, which are mostly focused around performance and bug fixes.

The performance gains arent just figures on paper either. There was a real world improvement of around 12% on PHP 8.3 alone.

Re: Upcoming Hardening in PHP

#39

Post by p4bl0 »

Cthulhu_ wrote: post #34
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 { ...…

It might be too big a change on a language level given this has been in since forever, but it might be picked up by static analysis / a linter. I'd argue it's always better to have additional protections like this in a linter as the process of adding linter rules is easier and less impactful than making a language change. It's also always preferred to not add anything to the language imo; in this case, I'd opt to hav…

Indeed on the PHP internals mailing list some people were saying that it would be better to entirely deprecate passing extra arguments to a non-variadic function, without adding syntax/keyword to the language.

Re: Upcoming Hardening in PHP

#40

Post by Ayesh »

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

FWIW, core PHP functions do throw an ArgumentCountError when passing fewer OR more parameters than the signature allows.
Post reply on HN