Re: [Astlinux-devel] Astlinux PHP version

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

"PHP version not supported" should really only matter if the end customer
is intending to use PHP directly themselves.  As an embedded system, if PHP
access is restricted to use by services on, and maintained by, that
embedded system, then it shouldn't matter what version it is -- so long as
critical security fixes are applied.

That said, Astlinux has diverged a lot from buildroot over the years and is
way behind.  Diverged may be the wrong word.  But I don't think the "keep
it small" argument holds any more given available memory in router/gateway
devices.  I know it is a huge undertaking, but it might be a good idea to
think about re-architecting to build on current buildroot following their
recommendations on how to package product specific features.

Excuse me while I hide behind my kevlar shield to protect from the
incoming barrage of reasons why that is a bad idea :-)

David.

On Thu, Apr 14, 2022 at 11:07 AM Lonnie Abelbeck <li...@lo...>
wrote:

> Hi Michael,
>
> I took some time and looked into bumping the AstLinux PHP version to 7.4
> ... short answer, keep it at 7.2 with appropriate CVE fixes.
>
> We (AstLinux) do not build a full set of PHP modules, only what we need to
> lessen the security footprint and image size, as well as not exposing the
> lighttpd/php stack to the public (encouraged) and by default.
>
> We also externally re-build the source "/ext/date/lib/timezonedb.h" file
> to keep the timezone info up to date and as small as possible.
>
> With that in mind I scrutinized the Debian security-tracker for PHP [1]
> and found one applicable CVE (Debian ignored it) but was simple to add [2].
>
> Additionally, make lighttpd/php anonymize header version information [3].
>
> As as aside, it is a pity the PHP folks don't offer an LTS version with
> only security fixes.  It seems somewhat unreasonable to me to always be
> chasing the latest couple PHP versions, all containing "Backward
> Incompatible Changes".  As such, we do what we feel is best for our
> specific project and application.
>
> Lonnie
>
> [1] https://security-tracker.debian.org/tracker/source-package/php7.4
>
> [2]
> https://github.com/astlinux-project/astlinux/commit/ca0f690ac145cb61c21fd419187e110db1b95597
>
> [3]
> https://github.com/astlinux-project/astlinux/commit/d5210cd49b9f6450ec630e87f38ae4a44ad2b1d6
>
>
>
> > On Apr 13, 2022, at 8:13 PM, Michael Knill <
> mic...@ip...> wrote:
> >
> > Hi Lonnie
> >
> > Thanks for the info and sorry for the delayed response.
> >
> > I'm afraid that it is purely a high level mandate as you mentioned and I
> suspect it would be difficult to justify to them the addition of CVE's but
> I am intending on discussing this with them.
> > PHP 7.4 goes EoS after November so it would be a short term only fix
> anyway but would keep the security guys happy for a little while.
> >
> > Regards
> > Michael Knill
> >
> > On 12/4/22, 11:56 pm, "Lonnie Abelbeck" <li...@lo...>
> wrote:
> >
> >    Hi Michael,
> >
> >    Is this vulnerability check based on a specific CVE or just the fact
> there are bigger version numbers of PHP available?
> >
> >    Looking at Debian security PHP:
> >    https://security-tracker.debian.org/tracker/source-package/php7.4
> >
> >    There may be one CVE fix we could backport, though Debian opted to
> ignore it.
> >
> >    Some of the CVEs effect modules we don't build like "soap", one only
> applies to 7.4+, one only to Windows.
> >
> >    If there is a specific CVE of concern in PHP, please point it out.
> >
> >    If this is just some high-level mandates, like PHP >= 7.4 good, PHP <
> 7.4 bad, then I have a hard time working with that.
> >
> >    One issue with upgrading to PHP 7.4 is the internal libzip is no
> longer supported, and libzip dropped autoconf support with versions > 1.3.2
> and switched to only cmake.
> >
> >    Again, if there is a CVE of concern, please let me know.
> >
> >    Lonnie
> >
> >
> >
> >
> >> On Apr 12, 2022, at 12:59 AM, Michael Knill <
> mic...@ip...> wrote:
> >>
> >> Hi Devs
> >>
> >> One of our major wholesale providers has performed a vulnerability
> check on our Astlinux system and identified a few Medium and High
> vulnerabilities.
> >> Pretty sure we have rectified all the Mediums but the High one is the
> PHP version now not supported. Unfortunately there will be significant
> repercussions if I cannot get this sorted.
> >>
> >> So basically I need to go to PHP 7.4 which will take us to November or
> go to 8.x which I understand will require some significant changes to the
> current PHP code.
> >> Do I have any other option than to roll my own image? If not then I'm
> certainly going to need to outsource this task as we don't have the inhouse
> skills (or time).
> >>
> >> Thanks all.
> >>
> >> Regards
> >>
> >> Michael Knill
> >> Managing Director
> >>
> >> D: +61 2 6189 1360
> >> P: +61 2 6140 4656
> >> E: mic...@ip...
> >> W: ipcsolutions.com.au
> >>
> >> <image001.png>
> >> Smarter Business Communications
> >>
> >> _______________________________________________
> >> Astlinux-devel mailing list
> >> Ast...@li...
> >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> >
> >
> >    _______________________________________________
> >    Astlinux-devel mailing list
> >    Ast...@li...
> >    https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> >
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>