On 09/21/2016 05:43 AM, Прокси wrote:
On 2016-Sep-21 14:35, Adrian Sevcenco wrote:
On 09/21/2016 02:02 PM, Прокси wrote:

My server with CentOS 6.8 just failed PCI scan, so I'm looking into
vulnerable packages. PHP 5.3.3 have multiple vulnerabilities, some of
them are fixed/patched or have some kind of workaround. But I can't find
a way to fix this one. Red Hat state: under investigation.


This CVE is 6 months old, and it doesn't look like it will be fixed.
Does anyone knows the way to go around this? Except blocking mb_strcut()
you could try the unsupported php from remi repos... you can find there php 7.0 

I use CentOS because I need stable and patched packages, so I can be
sure that all applications work without unpleasant surprises. Going to
unsupported packages would be my last option.

I feel the same way but I find that it is generally safe and beneficial to update the LAMP stack on servers and the multimedia stack on the desktop.

Things like HTTP/2 are not available in the Apache that ships even with CentOS 7 and the PHP is so outdated that it causes problems when using third party projects because the developers of those projects aren't using anything that old anymore. And for the TLS stack, mobile really benefits from chacha20 ciphers.

With respect to multimedia, there's the fluendo codec pack but interestingly FireFox won't play mp3 with the fluendo codec pack, it wants the libmad plugin.

And even more bizarre, maybe they have fixed it, but GStreamer 1.x in CentOS 7 when it shipped was not capable of decoding the VP9 codec used in WebM2. CentOS 7 came with tools to encode VP9 but the GStreamer was too crusty to decode it, and the commercial fluendo plugins were of no help there - replacing the GStreamer 1.x packages with a modern build was the only option.

Stability is pointless when it doesn't serve the intended purpose.

PHP even in CentOS 7 should be updated for a production server.
CentOS mailing list

Reply via email to