Reading this I'm almost certain the firewall vendor is Palo Alto Networks. They included a PAN-OS setting verbatim and the SELinux config matches my experience.
- Rust didn't exist at the time
- Go didn't exist at the time
- nodejs didn't exist at the time
- Java and Python likely used too much resources for a once-in-a-while used GUI
Irrational hatred aside, that's literally what PHP was designed for.
Perl?
Perl 4 specifically of course though.
Not in 2005. Perl 5 all the way, baby!
Perl 5 was released in 1994. Palo Alto Networks was founded in 2005, so Perl 5 was certainly available when they built their first products and would have been a superior choice to either PHP or Perl 4.
Sure, you can do web apps in Perl with Catalyst or other frameworks, but the PHP developers are easier to find.
And then, after you develop entire GUIs in a language, it is a herculean effort to port that to another.
And lastly, JavaScript has its own issues too.
It is a huge effort even migrating from one PHP framework to another.
Coming back to your point, there is no single “page” to be migrated one at a time.
Is there a reason one URL at a time wouldn't work?
You can always take a look at the UI of a PAN device and use your browser in developer mode to see how it works and understand the concept of a web application.
I do not have a PAN device.
> it is not "one URL"
I never implied it was.
> it is an entire application, it does not have distinct "pages"
> the concept of a web application
Those are usually written in javascript and the client part could stay the same. If anything that kind of design makes it easier to replace the backend one URL at a time becasue the responses from the backend are simpler.
If they have something where the UI state is kept on the server and is relayed to the browser, that would be difficult to do anything with. But that's an especially terrible design that causes other problems, so if you're accusing them of having a design that bad please be explicit.
Perl 5 was the language of choice for CGI in that era, but PHP borrowed some of perl syntax and quickly displaced Perl in web usage.
Some perl programmers migrated to Embperl, but it didn't gain much momentum.
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.
And that is even with the assumption that other languages don't have issues - they do.
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.
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.
> 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.