> Irrational hatred aside, that's literally what PHP was designed for.
Yes, in 2005 you choose PHP, but in 20 years of operation, you don't revisit reconsider your architectural considerations? A fantastic avenue for hardening any product would be to replace a ~2MSLOC component (the PHP interpreter) with a 10K SLOC daemon that does only what you need.
When you're a startup, expediency and funding prevent this, but by the time you're selling "solutions" and baking designs into ASICs you could have prevented this attack by putting a fraction of the effort into software.
This is great to say with the benefit of hindsight but nobody is changing the underlying language of their well established product for literally no reason.
And that is even with the assumption that other languages don't have issues - they do.
> literally no reason
PHP being big and creaky was very well known. This has nothing to do with hindsight.
And it still is big and creaky. You can cite this comment the next time something like this happens to prove it's not hindsight bias.
> And that is even with the assumption that other languages don't have issues
Incorrect. Please do not strawman.
At which point during that 20 years do you decide to rewrite a ton of your production code just to change languages?
When you are making a lot of money and have a security analysis of your stack.
I’ve never worked anywhere that would have done that. If you have a Sec analysis and it says you have vulnerabilities you harden and fix those vulns. You don’t just say “ok full rewrite in $HOT_LANGUAGE!” For one thing, you’ll have to retrain or replace your entire team, who may mostly be $OLD_LANGUAGE specialists. And either feature freeze, or carry on feature development thus needing a larger team, and making the spec a moving target for the porting team.
Now, do I think that it may be more likely in 2027 than it was in 2007 or 2017? Absolutely. Depends on how well-documented and specified your existing system is. A rust rewrite or whatever is highly possible now for many codebases, probably.
I get that logically you would think that a very wealthy company would improve their technology once they had the resources to do that. But companies do not run by logic. They run by humans, making human decisions, motivated by almost every conceivable thing except logic.
> When you're a startup, expediency and funding prevent this, but by the time you're selling "solutions" and baking designs into ASICs you
.... are still run by the same startup people who think "working like a startup" was a good idea in the first place.
Right now I work with a bunch of people who came up working for startups. They are responsible for the products that make the company the most money. They are still on PHP 7.4.
I wonder if that's why Palo and PanOS have had so many vulnerabilities this year and last