Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANvqVdr4d8C_04Php5iP78eMfZOtat2a6LuCoqVXHojB1HE5yw@mail.gmail.com>
Date: Mon, 21 Nov 2016 12:26:02 -0600
From: Michael Babker <michael.babker@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: WordPress (all versions): SPOF, RCE, and Negligence

On Mon, Nov 21, 2016 at 11:32 AM, Ben Tasker <ben@...tasker.co.uk> wrote:

> There was a similar issue a while back where Joomla! decided to run a
> version check to ensure PHP version was >= 5.3.10. It broke a number of
> sites, and the most common fix seems to have been a core-hack to disable
> that check. The logic for inserting that check was reasonable, but lacked
> consideration of who the market actually is.


While I can somewhat understand why the Linux distributions choose the
model they use for their "long term support" packages, it honestly does a
disservice to those of us who now have to defensively code around it.  We
can no longer rely on a package's version to accurately represent the state
of the code base.

I was Joomla's release lead at the time this decision was made.  We did not
arbitrarily choose a PHP version number, arbitrarily locking out vendor
modified PHP builds distributed with the LTS distros, just because we
wanted to.  We first attempted to implement bcrypt password hashing using
feature detection, after hacking the polyfill library to lower its PHP
minimum from 5.3.7 (which blocked some of its checks) to be able to try and
support the PHP 5.3.3 build the distros have elected to stabilize on and
modify.  This effort failed catastrophically, and our project collectively
decided we could not revert support for bcrypt hashed passwords and could
not try to support this feature using feature detection mechanisms; it was
too unreliable and we elected therefore to lock on a version number which
we knew would satisfy all of our requirements natively.  We could have
locked to 5.3.7 but elected to bump to 5.3.10 due to the security issues
fixed between those releases and at that point Ubuntu's LTS was at that
version so it helped us to make a logical choice.

While I understand where you are coming from, to be quite frank, I don't
believe the PHP ecosystem and its major players can continue to cater to
these modified PHP builds as might have been expected in years past.

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.