PHP 5 and 7.0 end of life
hackertarget.com
hackertarget.com
And of course this in-house guru for anything that happens on a screen patiently overwrites hacked 1.6 joomla installations by copying over an old copy and doesn't bother updating the passwords.
I am in the process of dockerizing almost everything in sight. There's pain.
I'm still maintaining some code written by someone like this - though it's been mostly replaced by a new rails app I've developed.
Is it not?
> certainly not unique to PHP
Doesn't stop it from being an issue in my book, one that prevents updating to newer versions of the interpreter without breaking production.
Some of them are more than 10 years old !
And as they represents a good share of my profits, I can’t dump them.
I think I saw a Joomla 1.5.
Those clients don’t want to pay someone to upgrade or redo their site.
There are several intranets that will not support PHP 7 because they use the old mysql_ functions...
So even I loose a lot of my semi-passive incomes, or I continue to tell them on a regular base that they should upgrade.
(For the anecdote, there were around 40 websites before I alerted my clients in April. 5 of them have migrate to last versions of Wordpress or joomla. 35 more to go...)
https://github.com/dshafik/php7-mysql-shim
It won't be 100% perfect and it's definitely not something I'd want to use long term, but it can help with the initial migration to PHP 7.
While I'm using https://github.com/dshafik/php7-mysql-shim, another to look at is https://github.com/mattbit/mysql-compat
phpcs + PHPCompatibility ruleset is pretty good about finding issues as well.
It's mainly what prevents me to migrate them by myself. It's a lot of work and no one wants to pay for it.
So it remains on a VM and if it brokes, they were alerted it could happen.
Keep in mind that the majority of people who need PHP (and technology in general...) have far more important things to do with their time than incessant trendchasing.
The saying about "known unknowns" and "unknown unknowns" is worth remembering too. The fact that a system has stayed working for over a decade should be enough to tell you that its creators did something right.
(I am in the process of restoring an 80-year-old refrigerator. ;-)
Never look under the hood at any of the companies involved in silicon development then. Server 2003 would be an upgrade for many, many tester machines.
To get to the "why dont they update" question:
1. Proprietary hardware with a custom driver.
2. Barely functional proprietary software, good luck getting it to run on anything except Windows XP/95/3.11.
3. The tester is LONG out of support.
4. The company that makes it is either out of business or was bought up by Teradyne/Advantest
5. The software is licensed specifically for that hardware it came with(CPU/Motherboard guids/serials, MAC addresses, etc).
6. If there is even a replacement for the tester, it will cost a minimum of $500k to replace, probably $1MM or more.
7. A customer requirement is to have external access, as much as IT fights it, the tester must also have internet access so the customer can send/receive files with their own workflow.
Sometimes we got lucky and I was able to push forward multiple upgrade projects moving testers from Windows XP to Windows 10. This was the case with most anything using a National Instruments GPIB where the software wasnt also locked down. Since National Instruments makes drives compatible with Windows 10 for their PCI cards, we were able to transition to Windows 10 on an entire floor once I developed a compatibility shim to get around the non-UAC assumptions of the tester software.
Example from 2018: A tester that runs on Windows XP meets all of the above. Capacitors on the P4 motherboard blew up, company was bought by Advantest, but they dont make that tester anymore or even have a replacement. It is one of three left on planet earth. What do we do? Replace everything we can. New RAM, SSD using an IDE to SATA bridge, PSU, etc. We sent the motherboard to one of our internal techs who replaced every single cap on the motherboard, by hand.
A few days later, it is back in action. It will remain in this condition for another decade or more, with internet access. This is normal in anything involved with manufacturing, and yes, it will all end badly. Thankfully, I am out of the Bay Area now and not at all involved with hardware manufacturing or that company, no longer supporting internet connected Windows 3.11, RHEL3, AIX4, and SunOS 2.6 machines.
1. In person.
2. Using VNC/telnet over a SSH gateway that dumps them onto the single broadcast network with all these testers.
Did I mention that changing the IP address on many of the testers is not possible without triggering a $10k+ licensing event because a change in the IP address invalidates the license file?
A $500k tester's depreciation is based on a 10+ year service life. The ones that make it past that point turn into security nightmares and profit centers at the same time.
These are large and complex machines, with hundreds or thousands of moving parts. A competent reverse engineer and driver developer likely could solve many of the driver interface issues and move things to newer platforms, but why invest hundreds of thousands per year in maybe updating something that still works? Who is going to pay for that? Oh, you want to raise your rates to pay for it? I guess they'll move all of their testing development to the competitor in Asia.
This isnt some big name you have heard of, but this is one of the places that all the big names go to to test their silicon during development.
That's very rarely the thought process in the real world when you're dealing with a production system though. Most developers who have the seniority and experience to make the call to upgrade something aren't just upgrading for the fun of it. It's more like...
"it's old and hundreds of security patches and performance improvements have been released in versions that have come along since it was current, and the core developers aren't supporting this version any more so we're in for a world of hurt if anything goes wrong, and we have the bandwidth to fix this problem right now where we might not in the future so let's change it"
you and i's experience varies greatly, Ive worked at a number of firms that update things based solely on age(and boredom) and nothing else... thats what happens when non-tech people steer the ship. I also see this happening a lot to justify someone existence on payroll.
Why do you need Docker to run a WAMP server?
I love docker for anything where I'm not going to be running whatever is in the repository of whatever Linux distribution I'm running.
Reminder: when that WAMP server is down (which is an issue all by itself, the physical server has downtime as well), everything is down. Even static websites.
Upgrading isn't just about shiny-shiny, and keeping old stuff isn't always best.
https://www.greenbuildingadvisor.com/article/choosing-an-ene...
What most people consider "old" for a fridge is probably late 70s/early 80s, and those ones did use a lot of power for some reason or other (usually defrost heaters); but the ones much older than that used far less.
I'm restoring it, which does mean rewiring and putting better insulation in the cabinet, but other than that the refrigeration system itself is still original and sealed (that's why they can last almost indefinitely.) If anything, it would likely make it even more efficient.
https://www.thegeoexchange.org/fridge-power-consumption/inde... - shows a saving of two-thirds by replacing a 20yo fridge with a mid-range model (they say they could have saved about 80% power use with a more expensive model).
https://www.youtube.com/watch?v=k_ysVqppaN0
The article you posted shows they went from 1300kWh/yr to 412kWh/yr. Amusing that it says "Some use as little as 255 kwh/year" when the article I posted mentions 244kWh/yr for the 30s Monitor-Top. (Mine is a "flat top" but has a very similar refrigeration system.) Like I said, average power consumption went up after the late 60s/early 70s, but before that they used less.
The compressor in mine draws <100W when running. A quick calculation shows that if it was running 24/7 that would be almost 900kWh/yr, but it definitely won't be running that much --- duty cycles I've found for these old ones vary from 15-20%, giving around 200kWh/yr, still very good. How often you open it and/or put warm things in probably has a higher impact on total power consumption than anything else.
This is extremely surprising, no. Motor/compressor/refrigerant/insulation design have all improved considerably.
Any insight there?
Usage patterns clearly have an impact, but I doubt they change much for a particular family across models -- some models have little doors for heavy use items to reduce air exchange, compartments probably make a big difference ('glass' shelves instead of wire).
Interesting. /beardStroke
In fact, the newer "environmentally friendly" refrigerants are less efficient than CFCs... so it's sort of a tradeoff between risking more ozone depletion when they leak, or putting more CO2 into the atmosphere from the higher power consumption...
If you don't update your software regularly, then future updates get harder and harder. Unfortunately, future updates might include security patches that are critical. At that point your choices are both bad: do a major catch-up update under crisis mode, or decline the update and roll the dice on a security incident (which will put you into crisis mode if if happens).
Incremental LAMP stack updates are so easy... they rarely break things, and there are so many other people doing the same thing, there is tons of community advice and help. If a developer is not capable of doing that, what ARE they capable of doing?
I won't get into details but the thing isn't stable and the last hack brought down some part of an emergency infrastructure for a whole region of a small country.
So, yeah... not stable, not safe.
Look at it this way. In 15 years time, that ancient docker setup may well be as insecure, unmaintainable and poorly-regarded as PHP5 is today. And another generation of admins and developers will repeat the cycle all over again with the new hotness of day.
Surprise, surprise, when you don't maintain and update your stack it becomes unmaintainable and insecure. News at 11.
Why the heck are you implying that updating it now means we don't manage and update it for the next 15 years ?
What do you suggest, then ? Keep things as is ? I remind you that the thing is insecure as fuck and it becomes hard to add features or patch the app because it's running on an old version of apache/php/mysql.
If you decide to drop dockerized setup in the future, I imagine it should be easy to do so as all you need is move the source code to the new host, is it not?
It just all sounded to me like someone hating at one dude who did crappy development and then tries to solve that problem with Docker instead of a process.
In my eyes, Docker is the epitome of crappy development. "Oh we don't care anymore, we just throw all into a container and be done with it."
That's actually the plan. We need to keep it running in legacy mode until the updated and patched version of the app is ready to be deployed. Main org IT don't want EOL and unsupported pieces in its infra anymore unless it can isolate it.
Next version is going to be service based and scalable. A WAMP installation can't do that.
Am I being trolled ? Because I don't see the people bashing docker or glorifying the values of an insecure but simple setup giving alternatives.
What should we do then ?
I just have the impression, Docker is the way if people don't really want to think about a solution.
How many other individuals in this clearly legacy organization have the knowledge and experience to take over your "superior" variant of technical debt once you get sick of the job and move to something trendier?
If they don't learn the soft way now they are going to learn the hard way later when the main org take away their admin privileges from their hands and restrict them to the php app.
The IT team is quite fed up with the incessant problems of this server (mail gateway got blacklisted for instance with the last incident). That server should have been retired but our resident guru has hit a mental roadblock regarding the migration.
I can't format the word enough so here it is with capital letters: DOCUMENTING.
> take over your "superior" variant of technical debt
Clearly the current server situation (one guy knows how to run it) is vastly superior to documenting it for others and not patching security holes is okay.
At least now we'll be able to shut down a particular service instead of shutting down the whole dept. next time that server hiccups.
Which also made me think - does anybody know an example of a widely used programming language that voluntarily discontinued?
https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion...
It's Java, so it has as much power and expressiveness as Java.
Well, I'd argue that PHP and Python were roughly equally easy, although they didn't "blend" into the HTML as well (which is good or bad, depending on your viewpoint). ASP was supposed to be just as easy, but I remember some of those code bases being pretty woolly.
Nowadays, I think we actually have it easier. I haven't used many of the other front-end frameworks, but you can design/generate a back-end in a few minutes using Open API Spec, add a persistence layer in a few more minutes, and wire it up to a Vue front-end very quickly. And the kicker is that it's modular and maintainable, which a lot of CF/PHP/ASP projects certainly were not.
no, it's not even close. you'd have to learn a whole javscript framework, read the open api spec, grok backend vs frontend, and really understand the modern web before you could even get started, not to mention the fomo induced by the hundreds of other options you'd have to discard in the process. for the average human, that's a non-starter.
with tag-based coldfusion, it felt like you were learning an extension to html, rather than an entirely different (programming) language. while php/asp were somewhat easy to learn, coldfusion was extra-super-duper-easy (i taught classes back in the day). people with no prior experience could create a dynamic web page in an hour or two and feel that sense of accomplishment that drove them deeper into it.
Python 2
Thanks for changing the title, whoever did it. This definitely sounded like PHP as a whole is dead. There's more than enough FUD surrounding PHP out there really.
There likely are many, many proprietary languages that were officially discontinued at some time.
Just the other day, a somewhat technical client of mine called me to ask if his PHP 7.0 installation has gaping security holes. I said no, you're using Ubuntu 16.04 LTS, you'll be fine until April 2021. If you force an upgrade now, you might run out of support even earlier.
My go-to version for production right now is PHP 7.2. I'm going to ignore all warnings about its EOL until 2028, when support for Ubuntu 18.04 runs out. Wait a sec, add another year for RHEL/CentOS 8 which is also going to support PHP 7.2 for the next 10 years. PHP 7.2 is going to outlive a whole bunch of future versions.
I'm not sure you can just hide behind the LTS assurance of the OS, they can't guarantee every single package in their repos will remain safe. Plenty of packages in Ubuntu LTS releases reach EoL far far before OS EoL.
Ubuntu for example has a pretty good track record of backporting PHP security fixes. PHP 7.0 in Ubuntu 16.04 has been getting updates every few weeks despite the EOL last winter, and I remember observing the same with PHP 5.5 in 14.04 until the OS itself reached EOL earlier this year.
The fact that both Red Hat and Canonical are committed to supporting PHP 7.2 for the next decade probably means that there will be more eyes on that particular version, and more hands to patch it, for the foreseeable future. It's a nice coincidence for people who want a bit of stability now that PHP has begun to change rather quickly.
I wonder if any of that work get up-streamed into the old versions for the benefit of other distros?
The majority of patches still come from upstream. If a new vulnerability is found in PHP 7.1 or 7.2, chances are the same bug exists in 7.0. So the maintainers check if their versions are also vulnerable, and if so, backport the fixes. As time goes on and differences accumulate, patches from upstream will become less relevant. It looks like Red Hat largely gave up on maintaining PHP 5.3 in RHEL/CentOS 6 after about 7 years. We'll have to see how long they actually stand behind PHP in CentOS 7 and 8.
Where I work I develop a web app that's written in Rails, and it's replacing a legacy PHP 5.6 app. Now here's the thing - no-one is using the PHP app anymore, but we do still have some old data on there that we made a decision not to port over to the new app. At the time it seemed like it wouldn't be a problem - just keep an old version of the app up for those who need to view historical information.
Now I'm thinking I'll have to set aside some time to either port it to PHP 7 (which isn't really a priority) or come up with something else for viewing that historical data.
Another problem are the Docker images. The PHP project still provides Docker Images for 5.6, however to my knowledge they are not updated anymore (perhaps I'm wrong). So what about all the security vulnerabilities in the underlying linux image? (I just verified and the latest php 5.6 image is from January 2019)
That being said, using a newer underlying Linux image for a Docker image is as copying the Dockerfile and building it, isn't it?
I think the PHP project should simply delete the 5.6 image, since it is insecure and EOL'ed. Then if somebody is interested they can provide an alternative image somewhere...
As are many/most PHP 5.6 projects
> Probably their code should not be used.
In reality it is - unfortunately. And many smaller companies don't have the capacity to change.
I'd be more concerned about having a Magento 1 site in the wild, than the upgrade path to PHP 7.
Like the other commenter said, PHO 5.6 to 7 upgrade isn't that hard. If it is, there's a very good chance they are doing something devastatingly wrong (like using mysql_ extension).
While upgrading from PHP 5.4 or lower to 7 can be... interesting, it's not all that difficult or time-consuming. PHP 5.5 or higher to 7 is much easier.
The issue is that when you have smaller companies with small web development departments you end up with a lot of differents sites/tools made over time. So now when it comes upgrade time you have a large pile of stuff that needs upgrading. One developer making new websites over a few years time isn't that crazy, so unfortunately you end up with a build-up of projects to update.
Yet while having time pressures to update, you also have pressures to continue to work on new things or fixing problems users have reported.
It usually comes down to time/money. Unfortunately dedicating time to updating things is never as high of a priority as making new things, adding new features, or fixing bugs. Because it follows the traditional mindset of it's working, why update it.
This is a little like having the money to buy a hand-made car, but only being able to afford ever other oil change.
If the business decides the risk is acceptable, then that's fine. As an engineer, you're supposed to communicate and document the risks associated with technical decisions. After that, if your employer decides Technology X.Y is good enough, then accept it and move on. You made your case, and the business considered it and made a choice.
It's [modded] cPanel hosting, with extras, so perhaps that's a cPanel thing but as a very small scale setup it helped a lot to be forewarned of incompatible plugins.
I upgraded a large project last month, and this found 6 changes I had to make in 20k LOC.
PHP 8 isn’t even out yet. How can PHP 7 already be deprecated and not even supported?