[RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions

On 10 Feb 2015, at 9:29 am, "Anatol Belski" anatol.php@belski.net
wrote:

Hi,

the voting on the removals in PHP7 in hereby finished. The results
are

item yes:no

sapi/aolserver 32:0
sapi/apache 32:0
sapi/apache_hooks 31:0
sapi/apache2filter 23:1
sapi/caudium 30:0
sapi/continuity 28:0
sapi/isapi 28:0
sapi/milter 10:9
sapi/phttpd 26:0
sapi/pi3web 24:0
sapi/roxen 23:0
sapi/thttpd 25:0
sapi/tux 25:0
sapi/webjames 25:0
ext/imap 14:19
ext/mcrypt 15:18
ext/mssql 17:13
ext/pdo_dblib 4:18
ext/sybase_ct 17:1

As most of the items are considered to be removed, the ones to stay
untouched by the 50%+1 requirement are

ext/imap
ext/mcrypt
ext/pdo_dblib

I'm going to implement and tag the changes considered ASAP. Regarding
the
stuff to considered to be removed from the core - if there are some
supporters, the sources will be made available in the git tag. They
can be
anytime ported to PHP7 and possibly resurrected.

Regards

Anatol

--

Does this mean PHP will be taking on the role of maintaining libmcrypt
as well? If a security issue is found, what is the course of action?

It means people want to find some more friendly way of moving forward rather than deleting the extension and letting users deal with the consequences.

I don't think anyone has suggested maintaining the underlying library. Several have suggested attempting to build at least a partial compatibility layer on top of openssl or other maintained libraries. Others have suggested adding aggressive warnings whenever the extension is used. I'm sure more suggestions will follow.

What is clear is that something should be done, but that consensus was that simple removal was not appropriate in this case.

Regards,

Rowan Collins
[IMSoP]

Does this mean PHP will be taking on the role of maintaining libmcrypt as well?

That's not what it means, no.

If a security issue is found, what is the course of action?

Well, what happened when there was vulnerabilities in OpenSSL?

I've been thinking quite hard about what we should do with regard to
mcrypt. We definitely need a plan to sunset it, but we can't really do
that without a readily available replacement. It's understandable if
people do not want to use OpenSSL as an alternative.

Hi David,

On 10 Feb 2015, at 9:29 am, "Anatol Belski" anatol.php@belski.net

wrote:

Hi,

the voting on the removals in PHP7 in hereby finished. The results are

item yes:no

sapi/aolserver 32:0 sapi/apache 32:0 sapi/apache_hooks
31:0
sapi/apache2filter 23:1 sapi/caudium 30:0 sapi/continuity
28:0
sapi/isapi 28:0 sapi/milter 10:9 sapi/phttpd
26:0
sapi/pi3web 24:0 sapi/roxen 23:0 sapi/thttpd
25:0
sapi/tux 25:0 sapi/webjames 25:0 ext/imap
14:19
ext/mcrypt 15:18 ext/mssql 17:13 ext/pdo_dblib
4:18
ext/sybase_ct 17:1

As most of the items are considered to be removed, the ones to stay
untouched by the 50%+1 requirement are

ext/imap ext/mcrypt ext/pdo_dblib

I'm going to implement and tag the changes considered ASAP. Regarding

the

stuff to considered to be removed from the core - if there are some
supporters, the sources will be made available in the git tag. They can

be

anytime ported to PHP7 and possibly resurrected.

Regards

Anatol

--

Does this mean PHP will be taking on the role of maintaining libmcrypt as
well? If a security issue is found, what is the course of action?

not that I knew, libmcrypt is not maintained. An alternative were openssl
probably.

Regards

Anatol

Hi David,

On 10 Feb 2015, at 9:29 am, "Anatol Belski" anatol.php@belski.net

wrote:

Hi,

the voting on the removals in PHP7 in hereby finished. The results are

item yes:no

sapi/aolserver 32:0 sapi/apache 32:0 sapi/apache_hooks
31:0
sapi/apache2filter 23:1 sapi/caudium 30:0 sapi/continuity
28:0
sapi/isapi 28:0 sapi/milter 10:9 sapi/phttpd
26:0
sapi/pi3web 24:0 sapi/roxen 23:0 sapi/thttpd
25:0
sapi/tux 25:0 sapi/webjames 25:0 ext/imap
14:19
ext/mcrypt 15:18 ext/mssql 17:13 ext/pdo_dblib
4:18
ext/sybase_ct 17:1

As most of the items are considered to be removed, the ones to stay
untouched by the 50%+1 requirement are

ext/imap ext/mcrypt ext/pdo_dblib

I'm going to implement and tag the changes considered ASAP. Regarding

the

stuff to considered to be removed from the core - if there are some
supporters, the sources will be made available in the git tag. They can

be

anytime ported to PHP7 and possibly resurrected.

Regards

Anatol

--

Does this mean PHP will be taking on the role of maintaining libmcrypt as
well? If a security issue is found, what is the course of action?

not that I knew, libmcrypt is not maintained. An alternative were openssl
probably.

Regards

Anatol

Hi Paul

2015-02-10 23:59 GMT+01:00 Paul Dragoonis dragoonis@gmail.com:

Did you accidentally miss out mssql? it resultes in significant resistance
to leave core, such as mcrypt and ignoring mathematical numbers, from a
practical basis I'd like to see mssql kept in core. Who's with me ?

I'd like to see mssql kept as well, only makes more sense as we also
have pdo_dblib. I wouldn't mind looking into some fixes to it or
porting it once I get my FreeTDS or ntwdblib configuration setup here,
as there is a fair bit of cleanup I'd like to do with it.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

On Mon, Feb 9, 2015 at 10:29 PM, Anatol Belski anatol.php@belski.net
wrote:

ext/mssql 17:13

Did you accidentally miss out mssql? it resultes in significant resistance
to leave core, such as mcrypt and ignoring mathematical numbers, from a
practical basis I'd like to see mssql kept in core. Who's with me ?

Since it's apparently my week for this, I'll provide the case for the
defence (or why I voted for removal, anyway):

• The API is awful in the exact same ways the ext/mysql API was awful
  — it makes it far harder to write secure code than it should be.

• Actually, it's worse than that, because there's no charset-aware
  escaping function at all: the only option is addslashes(), which has
  interesting security implications if you're using certain charsets.

• It's buggy. Some of the bugs are due to the underlying library
  (which is mostly dead); some are in our code, but there are some
  fundamental issues — basic data types (nvarchar(128), for example)
  aren't supported, field names are truncated, stored procedure calls
  are problematic, and probably many more things that I've forgotten.

• The bugs probably aren't going to be fixed. ext/mssql averages about
  one to two non-whitespace, non-copyright-year-increment commits a
  year. A cursory look at the bug tracker (or my ##php logs) will tell
  you that it's not because it's stable and free of bugs.

• There are multiple better options: using ODBC is almost always more
  stable, and while PDO_dblib has some of the same problems due to
  FreeTDS, at least you're using PDO's better (by which I mostly mean
  harder to misuse) API.

In my mind, this is analogous to removing ext/mysql: it's the right
thing to do for our users because it promotes better practices and
gets rid of an extension that has even more technical issues than that
one did.

Finally, Anatol's tally was wrong for this one: it was 17:3 for
removal. That's a pretty strong indicator by itself.

Adam

Hi,

ext/imap
ext/mcrypt
ext/pdo_dblib

Sorry if this was suggested already but if those are not maintained much and
should not be used further ideally, shouldn't we add E_DEPRECATED to them at
least?

I understand that they are kept to avoid making the upgrade path harsher,
but it's also not great to let they linger on forever with no notice to
users that they are doing something wrong.

I don't think it has been suggested already, but I agree - should be deprecated.

Cheers,
Andrey.

Jordi Boggiano wrote on 11/02/2015 10:40:

ext/imap
ext/mcrypt
ext/pdo_dblib

Sorry if this was suggested already but if those are not maintained
much and should not be used further ideally, shouldn't we add
E_DEPRECATED to them at least?

I understand that they are kept to avoid making the upgrade path
harsher, but it's also not great to let they linger on forever with no
notice to users that they are doing something wrong.

I guess that's a discussion that can be had on a case-by-case basis, now
we've bulk-voted the easy cases out of the way.

Deprecation only really makes sense if there is a clear upgrade path for
users, or a specific message to give them. For instance, I'm currently
using PDO_DBLIB, and had no idea I was "doing something wrong", or what
I should be doing instead. And many people have already pointed out that
ext/mcrypt needs some special thought, so just slapping a deprecation
notice somewhere isn't really that useful.

Regards,

Rowan Collins
[IMSoP]

Hi Jordi,

ext/imap ext/mcrypt ext/pdo_dblib

Sorry if this was suggested already but if those are not maintained much
and should not be used further ideally, shouldn't we add E_DEPRECATED to
them at least?

I understand that they are kept to avoid making the upgrade path
harsher, but it's also not great to let they linger on forever with no
notice to users that they are doing something wrong.

that was not suggested yet. IMHO the idea is healthy at least for imap and
mcrypt. I also think the most reasons to vote for the non removal was the
lack on alternatives as well, not just because the dependencies are
unsupported.

And another RFC were needed for this, obviously. I'm not disposed for yet
another one ATM, but that doesn't mean only me could do that.

Regards

Anatol