With PHP 5.6 and the Zend loader being very much end of life at this point, what’s the plan for the commercial side of things?
Even a rough idea would be great.
Two years. That’s my take on it. Maybe sooner but with the release cycles as they have been for the last 4-5 years that is what it would indicate. Back in April when Andrew made the “FreePBX Beta is Released” post he said that by FreePBX 16 is would be 100% PHP 7.x and commercial modules wouldn’t depend on Zend for encoding.
I recall. And then the whole guard changed. A two-year wait at this point stuck on PHP 5 would be ridiculous. In two years, PHP 7.3 will be nearly end of security fix support. (PHP: Supported Versions)
If there’s not a plan in place already, I would advocate for some community involvement in it. I’ve usually got two cents I’m willing to spend giving opinions.
I’d sure like to try out Zulu on my FreePBX 15 Debian 10 install.
I get the need for a “Distro” model that has everything exactly in place to make support easier. Some of us want to support our own systems and still have access to the extended features.
Yes and the new guard should have inherited any plans and roadmaps that existed for this. The state of such things, when inherited, would be the question.
I’m just going off what has happened in recent years. v13 - 2015, v14 - 2017, v15 - 2019. Believe me, I would love to see v16 in 2020 but the debt right now is just too big (I think). I mean the stable release of v15 requires you to immediately put the box on development tracks for things to work properly. HA has been in the wind for 2 releases and while v15 kinda, sorta, not officially supports PHP7.x (thanks to you mainly) its only for the OSS side so anyone wanting official support/commercial modules can’t benefit from it.
Plus you have the Asterisk stuff. Macro()'s need to be replaces, which is 95% of how FreePBX does things. Chan_SIP is on the “can be removed in 4 years” track and its still a big factor around the GUI. Plus anything else that comes along.
So there is a lot on the table right now for v16 to deal with.
1 Like
Zend is not the issue here. Zend works in debian (x86) This is a decision of what to support.
All platforms, Distro, PBXact and Switchvox are standardized on SNG7 so I don’t see Debian getting any official support. System admin which is required by commercial modules is all written for EL based systems too.
Note EL uses their own timetable (CentOS, RHEL, SNG). They backport security and bug fixes. So running an older php means you don’t get new features but you still get bug/security fixes.
PHP 5.6 was end-of-life including security fixes in January 2019. Where are they getting security fixes after that point?
2 Likes
This means 6 unpatched vulnerabilities so far
Hey Bill,
Unfortunately it’s too soon in the planning process for me to confirm any next targets.
That being said, getting onto a more modern version of PHP is of great interest for a number of reasons, and coupled with that, getting off of Zend and on something that better supports modern versions of PHP.
So, in short, at this point I can’t give any commitments, but those specific things weigh heavily on my mind as I start to thinking about what’s next.
We are always excited to accept any PHP 7.x compatibility patches though from anybody that wants to get a jump on it, as I’m sure the code is ripe with areas that will need to be fixed.
Great question, and hope you are doing well! Also, thanks for the patches you’ve already submitted in some of these directions.
Best wishes,
Matthew Fredrickson
1 Like
That behavior is impressive.
1 Like
I agree with @mattf updating to a more modern version is the best approach. Backporting seems to be a selective process and it is hard to tell what is fixed and what is not due to difference in versioning and naming between upstream, Enterprise Linux, and FreePBX. For example Red Hat does not seem to be planning to fix these vulnerabilities in Enterprise Linux 7 that are currently affecting PHP 5.6. Many users depends on the updates to secure their system. Compromised system mean money, time, effort and more importantly building a new system from scratch.
https://access.redhat.com/security/cve/cve-2019-9024
https://access.redhat.com/security/cve/cve-2019-6977
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.