Hi,
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.
Regards
Anatol
Hi,
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.Regards
Anatol
I get the motivation to drop dead SAPIs or extensions that require
unmaintained libraries.
However this list also contains a number of exts like ext/interbase where
people have explicitly stated in the discussion that the extension is still
supported and will be ported to PHP 7. Why do we vote to remove them? Or
did I misunderstand something?
Nikita
Hi,
Hi,
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.Regards
Anatol
I get the motivation to drop dead SAPIs or extensions that require
unmaintained libraries.However this list also contains a number of exts like ext/interbase where
people have explicitly stated in the discussion that the extension is still
supported and will be ported to PHP 7. Why do we vote to remove them? Or
did I misunderstand something?Nikita
I'd like to ask the same thing about oci8 and pdo_oci. I haven't dealt
with Oracle in awhile now, but last time I had to - it was still in
PECL, so ... why and where would it get removed from?
Cheers,
Andrey.
Oh, forgot one thing ...
Mcrypt might be dead, but removing it would be a huge BC break. There
was some talk of binding mcrypt_*() functions to ext/openssl - I'd
suggest that instead of removal.
Cheers,
Andrey.
Oh, forgot one thing ...
Mcrypt might be dead, but removing it would be a huge BC break. There
was some talk of binding mcrypt_*() functions to ext/openssl - I'd suggest
that instead of removal.
that sounds plausible, but the same one could say about mapping to be
removed regex to pcre. If anything of that is going to be happening, so I
would welcome another RFC and implementation.
Regards
Anatol
Hi,
I gave my votes (where I can talk about). I am still maintaining the NSAPI SAPI. It does not meant that its dead if no commits were made. NSAPI upstream API just did not change since years, so why change a running system?
The current version of this SAPI (5.6) runs perfectly with MediaWiki and several CMS systems on latest Oracle iPlanet server in production. The information about NSAPI you gave ("The developers of iPlanet @Oracle wrote back, that they're not intended to support this SAPI starting from PHP7 onwards.") is not applicable, because people from Sun/Oracle never provided any support or this extension - you should have asked the maintainer (me). Oracle just recommends fcgi, because it might be more stable if you use non-threadsafe extensions, but otherwise the server is perfectly stable and very fast. Oracle employees only helped with one patch, otherwise it was mostly (re-)written by me. In addition, the server works perfectly fine on Ubuntu 14.04, so it will also run on Debian. It can be downloaded with Oracle OTN license, header files are included. You can compile PHP 5.6 with it as documented: http://www.oracle.com/technetwork/java/webtier/downloads/iplanet-webserver-525365.html
If there are changes needed in the SAPI for PHP 7, I can take care, I just have not looked into it. It should not be a problem for me to update it, unless significant changes in the PHP API occurred since my last commit (yes, I am a bit inactive, but still following the development).
Uwe
Uwe Schindler
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-----Original Message-----
From: Anatol Belski [mailto:anatol.php@belski.net]
Sent: Monday, February 02, 2015 8:45 PM
To: Andrey Andreev
Cc: Nikita Popov; Anatol Belski; PHP internals
Subject: Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported
SAPIs and extensionsOh, forgot one thing ...
Mcrypt might be dead, but removing it would be a huge BC break. There
was some talk of binding mcrypt_*() functions to ext/openssl - I'd suggest
that instead of removal.that sounds plausible, but the same one could say about mapping to be
removed regex to pcre. If anything of that is going to be happening, so I
would welcome another RFC and implementation.Regards
Anatol
Hi Uwe,
Hi,
I gave my votes (where I can talk about). I am still maintaining the
NSAPI
SAPI. It does not meant that its dead if no commits were made. NSAPI
upstream API just did not change since years, so why change a running
system?The current version of this SAPI (5.6) runs perfectly with MediaWiki and
several CMS systems on latest Oracle iPlanet server in production. The
information about NSAPI you gave ("The developers of iPlanet @Oracle
wrote back, that they're not intended to support this SAPI starting from
PHP7
onwards.") is not applicable, because people from Sun/Oracle never
provided any support or this extension - you should have asked the
maintainer (me). Oracle just recommends fcgi, because it might be more
stable if you use non-threadsafe extensions, but otherwise the server is
perfectly stable and very fast. Oracle employees only helped with one
patch, otherwise it was mostly (re-)written by me. In addition, the server
works perfectly fine on Ubuntu 14.04, so it will also run on Debian. It
can be downloaded with Oracle OTN license, header files are included. You
can compile PHP 5.6 with it as documented:
http://www.oracle.com/technetwork/java/webtier/downloads/iplanet-webserve
r-525365.htmlIf there are changes needed in the SAPI for PHP 7, I can take care, I
just have not looked into it. It should not be a problem for me to update
it, unless significant changes in the PHP API occurred since my last
commit (yes, I am a bit inactive, but still following the development).
yeah, I saw your reply previously that it's worky with PHP5, however
couldn't test (whereby it turned out iPlanet is available not only for
SunOS). But then I had the reply from the @Oracle devs and thought it's
were cleared. Please check what happened to Apache SAPI (just to estimate
the efforts), there's quite some change after the phpng and TLS merge. If
you think it'd be acceptable for you to port and maintain in the ufture,
so lets restart the vote right now and exclude sapi/nsapi.
Thanks.
Anatol.
Hi,
Oh, forgot one thing ...
Mcrypt might be dead, but removing it would be a huge BC break. There
was some talk of binding mcrypt_*() functions to ext/openssl - I'd suggest
that instead of removal.that sounds plausible, but the same one could say about mapping to be
removed regex to pcre. If anything of that is going to be happening, so I
would welcome another RFC and implementation.
Not quite ... ereg has been deprecated since PHP 5.3, while mcrypt was
never deprecated and is extremely wide-spread in PHP code (that does
encryption) today.
Cheers,
Andrey.
Hi,
Hi,
On Mon, Feb 2, 2015 at 9:45 PM, Anatol Belski anatol.php@belski.net
wrote:Oh, forgot one thing ...
Mcrypt might be dead, but removing it would be a huge BC break. There
was some talk of binding mcrypt_*() functions to ext/openssl - I'd
suggest that instead of removal.that sounds plausible, but the same one could say about mapping to be
removed regex to pcre. If anything of that is going to be happening, so
I
would welcome another RFC and implementation.Not quite ... ereg has been deprecated since PHP 5.3, while mcrypt was
never deprecated and is extremely wide-spread in PHP code (that does
encryption) today.
yeah, looking at the openssl you've mentioned, and which was vulnerable to
any possible attacks last years, and has fixed those ... Asking myself,
how a library which wasn't updated since like eight years does feel :) Can
it still provide that really secure encryption? And should one provide
something like that as a secure solution?
Comparing with regex I meant, one could provide a replacing API. Just
where with regex it's more like functionality breach (whereby security as
well, as that lib wasn't revisited maybe for much longer than mcrypt),
with mcrypt it's a security weakness we would still try to sell for safe.
Regards
Anatol.
Hi,
Mcrypt might be dead, but removing it would be a huge BC break. There
was some talk of binding mcrypt_*() functions to ext/openssl - I'd
suggest that instead of removal.that sounds plausible, but the same one could say about mapping to be
removed regex to pcre. If anything of that is going to be happening, so
I
would welcome another RFC and implementation.Not quite ... ereg has been deprecated since PHP 5.3, while mcrypt was
never deprecated and is extremely wide-spread in PHP code (that does
encryption) today.yeah, looking at the openssl you've mentioned, and which was vulnerable to
any possible attacks last years, and has fixed those ... Asking myself,
how a library which wasn't updated since like eight years does feel :) Can
it still provide that really secure encryption? And should one provide
something like that as a secure solution?Comparing with regex I meant, one could provide a replacing API. Just
where with regex it's more like functionality breach (whereby security as
well, as that lib wasn't revisited maybe for much longer than mcrypt),
with mcrypt it's a security weakness we would still try to sell for safe.
Well, obviously mcrypt has to go away at some point - there's no
doubt about it.
I'm just saying it would be a massive BC break if that happens with no
prior deprecation. If somebody has the motivation to make the userland
API bind to ext/openssl under the hood, that's just a bonus in at
least depending on maintained code.
Cheers,
Andrey.
Hi,
On Mon, Feb 2, 2015 at 8:11 PM, Anatol Belski anatol.php@belski.net
wrote:Hi,
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.Regards
Anatol
I get the motivation to drop dead SAPIs or extensions that require
unmaintained libraries.However this list also contains a number of exts like ext/interbase where
people have explicitly stated in the discussion that the extension is
still supported and will be ported to PHP 7. Why do we vote to remove
them? Or did I misunderstand something?
yeah, frankly I was waiting for at least one voice for these extensions to
exclude them from the vote (and I was also explicitly sending a reminder
for this RFC last week). And I anyway didn't believe them to be voted
"yes" because it's mentioned they're going to be supported. Now interbase
and pdo are excluded from the voting, as per multiple requests. It's not
21:00 CET yet, so hereby the voting is started.
Thanks.
Anatol.
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.
I feel this is totally out of line since only people who use modules
will have the need to retain them, but like me many of those people have
no right to vote!
I have not yet found any problem running interbase with 'master' and I
am sure the warnings being raised simply require the assistance of
someone who understands why a change has been made, rather than it being
essential that we have to learn that knowledge JUST to keep an existing
extension working.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.I feel this is totally out of line since only people who use modules
will have the need to retain them, but like me many of those people have
no right to vote!I have not yet found any problem running interbase with 'master' and I
am sure the warnings being raised simply require the assistance of
someone who understands why a change has been made, rather than it being
essential that we have to learn that knowledge JUST to keep an existing
extension working.
What about moving pdo_firebird to pecl too? Last time I checked it was
fairly broken (compared to ext/interbase).
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Hi Matteo,
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09
at 21:00 CET.I feel this is totally out of line since only people who use modules
will have the need to retain them, but like me many of those people have
no right to vote!I have not yet found any problem running interbase with 'master' and I
am sure the warnings being raised simply require the assistance of
someone who understands why a change has been made, rather than it
being essential that we have to learn that knowledge JUST to keep an
existing extension working.What about moving pdo_firebird to pecl too? Last time I checked it was
fairly broken (compared to ext/interbase).
Marius Adrian Popa has stated to maintain both, and looks like there
several active users who will use that. So going by that, it's not being
voted on these exts.
Regards
Anatol
Marius Adrian Popa has stated to maintain both, and looks like there
several active users who will use that. So going by that, it's not being
voted on these exts.
I must have missed that, sorry for the noise.
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Marius Adrian Popa has stated to maintain both, and looks like there
several active users who will use that. So going by that, it's not being
voted on these exts.I must have missed that, sorry for the noise.
This is a bit of the problem here. There is a substantial Firebird user
base who like wordpress and joomla users have no knowledge of what is
going on in the background to keep their platform working. Often we
don't find out about things - 'they get missed' - but similarly just
treading water takes too much time today so following development on
everything we do use often takes second place?
I wonder if ANY mssql users have noticed that they may be left out of
PHP7 ... I suspect that may actually have a bigger user base than the
paid for 'Interbase' yet it's got no support here.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Marius Adrian Popa has stated to maintain both, and looks like there
several active users who will use that. So going by that, it's not
being
voted on these exts.I must have missed that, sorry for the noise.
This is a bit of the problem here. There is a substantial Firebird user
base who like wordpress and joomla users have no knowledge of what is
going on in the background to keep their platform working. Often we
don't find out about things - 'they get missed' - but similarly just
treading water takes too much time today so following development on
everything we do use often takes second place?I wonder if ANY mssql users have noticed that they may be left out of
PHP7 ... I suspect that may actually have a bigger user base than the
paid for 'Interbase' yet it's got no support here.
For mssql, most of them (while we see more and more requests from linux
lately) are on windows. And mssql support has been removed with the release
of 5.3.0. Since 2 years they use sqlsrv from pecl.
I wonder if ANY mssql users have noticed that they may be left out of
PHP7 ... I suspect that may actually have a bigger user base than the
paid for 'Interbase' yet it's got no support here.For mssql, most of them (while we see more and more requests from linux
lately) are on windows. And mssql support has been removed with the
release of 5.3.0. Since 2 years they use sqlsrv from pecl.
I spotted the reference to using ODBC as an alternative as well which
does get used for Firebird in some areas. The point perhaps is that like
mysql, the information as to what IS the preferred method of working
these days is not being linked to the discussion? There is useful
material on a number of these 'removals' but it's all mixed up in the
one thread :(
Separate 'crib sheets' to support each eventual change?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Pierre Joye wrote on 03/02/2015 09:14:
Marius Adrian Popa has stated to maintain both, and looks like there
several active users who will use that. So going by that, it's not
being
voted on these exts.
I must have missed that, sorry for the noise.
This is a bit of the problem here. There is a substantial Firebird user
base who like wordpress and joomla users have no knowledge of what is
going on in the background to keep their platform working. Often we
don't find out about things - 'they get missed' - but similarly just
treading water takes too much time today so following development on
everything we do use often takes second place?I wonder if ANY mssql users have noticed that they may be left out of
PHP7 ... I suspect that may actually have a bigger user base than the
paid for 'Interbase' yet it's got no support here.
For mssql, most of them (while we see more and more requests from linux
lately) are on windows. And mssql support has been removed with the release
of 5.3.0. Since 2 years they use sqlsrv from pecl.
For what it's worth, we've been running a Linux + MS SQL setup for
around 10 years, due to a previous migration from Classic ASP to PHP. We
originally used ext/mssql, and moved to ext/pdo_dblib with PHP 5.4
(previous versions didn't support nextRowset(), which made it unusable).
Both run smoothly on current Ubuntu builds with FreeTDS installed.
While we've almost succeeded in deprecating the legacy DBs in favour of
Postgres, it could easily happen that someone is just starting down the
same route now, and would want to know what driver will work best with
PHP 7.
As others have hinted, maybe there could be a table somewhere of the
recommended drivers (and db-specific exts, where applicable) to use for
different OS/DB combinations? This could answer both "if I'm a PHP user,
which configuration should I be choosing for reasonable
future-proofing?" and "if I'm an extension developer, where should I be
contributing features?".
Regards,
Rowan Collins
[IMSoP]
For what it's worth, we've been running a Linux + MS SQL setup for
around 10 years, due to a previous migration from Classic ASP to PHP. We
originally used ext/mssql, and moved to ext/pdo_dblib with PHP 5.4
(previous versions didn't support nextRowset(), which made it unusable).
Both run smoothly on current Ubuntu builds with FreeTDS installed.While we've almost succeeded in deprecating the legacy DBs in favour of
Postgres, it could easily happen that someone is just starting down the
same route now, and would want to know what driver will work best with
PHP 7.
I've still got some ASP sites, and have been using mssql in much the
same way but those sites will remain with PHP5.2 and the replacements
will be on the modern framework.
As others have hinted, maybe there could be a table somewhere of the
recommended drivers (and db-specific exts, where applicable) to use for
different OS/DB combinations? This could answer both "if I'm a PHP user,
which configuration should I be choosing for reasonable
future-proofing?" and "if I'm an extension developer, where should I be
contributing features?".
I think third part libraries like ADOdb probably need a similar
treatment. My use of mssql is via that and other legacy drivers are
similarly wrapped, but tagging alternative paths there can only help,
and is something I can document.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi,
Hi,
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.
I have to resend this announcement, because there was some changes based
on the shortly given feedbacks. The following was excluded from the votes:
ext/interbase
ext/oci8
ext/pdo_oci
sapi/nsapi
These items are going to become maintanance for PHP7. In intention to
bring this RFC forward, I've decided to just restart the vote settling it
for 2015-02-02 to 2015-02-09 at 23:00 CET respectively.
If there is someone who gave a vote for one of the mentioned items, it
counts as a wimp. If there are more doubtful cases, or someone thinks
these items was removed from the vote unappropriately, there'll be
probably no option than to defer the voting until everything was cleared.
Regards
Anatol
The voting ends on 2015-02-09 at 21:00 CET.
This is a ridiculously short voting period for a major decision.
Although the minimum voting time for an RFC is one week, that should
only be used in extremis.
The people affected by this decision are not likely to read PHP
internals every day or even every week.
This voting period should be left open as long as possible, probably
as close to PHP 7's alpha date as feasible.
cheers
Dan
Hi Danack,
The voting ends on 2015-02-09 at 21:00 CET.
This is a ridiculously short voting period for a major decision.
Although the minimum voting time for an RFC is one week, that should
only be used in extremis.
I wouldn’t say one week is “in extremis” - it’s reasonable for small, self-contained, BC break-less new features. Although at least 10 days is usually better.
That being said, I agree. This kind of thing shouldn’t be taken lightly, and this RFC should have a longer voting period.
The people affected by this decision are not likely to read PHP
internals every day or even every week.
Yeah, I agree here. The fact there’s not been much discussion attests to that.
+1
--
Andrea Faulds
http://ajf.me/
Hi Andrea,
Hi Danack,
On 2 February 2015 at 19:11, Anatol Belski anatol.php@belski.net
wrote:The voting ends on 2015-02-09 at 21:00 CET.
This is a ridiculously short voting period for a major decision.
Although the minimum voting time for an RFC is one week, that should
only be used in extremis.I wouldn’t say one week is “in extremis” - it’s reasonable for small,
self-contained, BC break-less new features. Although at least 10 days is
usually better.
This topic was spoken long before the discussion was started. It's also
not that the subjects would be erased from existence, they'll be moved to
a separate branch, that's all. Furthermore, they're available for a while
in the lower branches (non PHP7 ported, so almost the same state). And
anyone interested is free to resurrect something or put into PECL.
That being said, I agree. This kind of thing shouldn’t be taken lightly,
and this RFC should have a longer voting period.The people affected by this decision are not likely to read PHP
internals every day or even every week.Yeah, I agree here. The fact there’s not been much discussion attests to
that.+1
We could hold this open far much longer, that's true. However that
obviously wouldn't help us to find maintainers for that stuff. On the
other hand - it would really bring PHP7 forward getting rid of things
where everyone agrees. As not having to do --disable-all all the time is a
certain plus. One needs not much time to check that.
I'd really suggest to put a "yes" or "no" at this point and have it done.
Whereby some "no" from an active developer in this case IMHO would mean
not just "no, that should stay in the core", but "yes, i'll help to port
and maintain it". However nobody is forced to mean or guarantee that, just
that at the end we can end up with some non ported pieces of core. IMHO we
should kick out what obviously doesn't fit anymore and move forward, as
the PHP7 deadline is quite tight.
Regards
Anatol
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.
To explain my -1s:
-
ext/imap and ext/mcrypt: while I realise that the underlying
libraries are dead, these extensions are too widely used to straight
up remove them, I fear — we don't have obvious alternatives with
simple enough APIs that we can push users towards. I'd strongly
support and encourage a reimplementation of these extensions (in C or
PHP) around something supported if someone was able to step up and do
the work, otherwise yes, I'll pitch in to do the minimal work to port
these to 7.0 if required. -
ext/pdo_dblib: ODBC is almost always the better way of interfacing
with SQL Server, but I don't think keeping this one around is doing
anyone much harm (as opposed to ext/mssql, which we should kill with
fire for the same reasons as ext/mysql).
Abstentions:
-
sapi/apache2filter: I wonder if someone would step up for that one
if we advertised more widely, given I believe that it is in actual
use. Unlike most of the other SAPIs, which are obviously dead, I'd
like to give this one a bit more time before the 7.0 feature freeze. -
sapi/milter: I'm at least passingly familiar with almost all of the
Web servers in the list, but I know nothing about the environments
this SAPI is used in. Can someone who is familiar with it describe the
pros and cons to dropping it? -
ext/sybase_ct: does PDO (via dblib and/or ODBC) cover this
functionality adequately? I feel that I know enough to vote on SQL
Server related topics, but haven't looked at actual Sybase for years.
Adam
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.To explain my -1s:
- ext/imap and ext/mcrypt: while I realise that the underlying
libraries are dead, these extensions are too widely used to straight
up remove them, I fear — we don't have obvious alternatives with
simple enough APIs that we can push users towards. I'd strongly
support and encourage a reimplementation of these extensions (in C or
PHP) around something supported if someone was able to step up and do
the work, otherwise yes, I'll pitch in to do the minimal work to port
these to 7.0 if required.
I understand your thoughts. How about if we do for mcrypt what we did for
mhash, I.e. implement a compatible layer on top of openssl? I have not
checked if it's even possible yet, just an idea that popped into mind. I
would be willing to do this to learn more about the openssl innards, so I'd
probably need someone else to verify my work.
- ext/pdo_dblib: ODBC is almost always the better way of interfacing
with SQL Server, but I don't think keeping this one around is doing
anyone much harm (as opposed to ext/mssql, which we should kill with
fire for the same reasons as ext/mysql).Abstentions:
- sapi/apache2filter: I wonder if someone would step up for that one
if we advertised more widely, given I believe that it is in actual
use. Unlike most of the other SAPIs, which are obviously dead, I'd
like to give this one a bit more time before the 7.0 feature freeze.
Is this really used? It's been here before Apache2handler, bit my guess is,
just because filters were new and cool.
- sapi/milter: I'm at least passingly familiar with almost all of the
Web servers in the list, but I know nothing about the environments
this SAPI is used in. Can someone who is familiar with it describe the
pros and cons to dropping it?
Sendmail mailfilter API. I did one odd fix in the past, but the bug was
old, and the reporter didn't come back.
- ext/sybase_ct: does PDO (via dblib and/or ODBC) cover this
functionality adequately? I feel that I know enough to vote on SQL
Server related topics, but haven't looked at actual Sybase for years.Adam
Hi Michael,
I understand your thoughts. How about if we do for mcrypt what we did for
mhash, I.e. implement a compatible layer on top of openssl? I have not
checked if it's even possible yet, just an idea that popped into mind. I
would be willing to do this to learn more about the openssl innards, so
I'd
probably need someone else to verify my work.
if you venture to do this, please ping. I can support you at least with
testing and maybe more.
Regards
Anatol
"Anatol Belski" in php.internals (Tue, 3 Feb 2015 09:11:18 +0100):
Hi Michael,
I understand your thoughts. How about if we do for mcrypt what we did for
mhash, I.e. implement a compatible layer on top of openssl? I have not
checked if it's even possible yet, just an idea that popped into mind. I
would be willing to do this to learn more about the openssl innards, so
I'd probably need someone else to verify my work.if you venture to do this, please ping. I can support you at least with
testing and maybe more.
Daniel Stenberg (curl dev) happened to point to libtomcrypt today:
https://github.com/libtom/libtomcrypt
Jan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 03/02/2015 08:10, Adam Harvey a écrit :
To explain my -1s:
- ext/imap and ext/mcrypt: while I realise that the underlying
libraries are dead,
This means, if we want to keep them, we have to take ownership and
maintain those libraries.
Do you really want to do this ?
these extensions are too widely used to straight up remove them,
For mcrypt, I think lot of project use it as optional
(perhaps, at least, because a Enterprise distro doesn't provide it)
Recently phpMyAdmin have switch to openssl first.
Remember, if it is dropped from PHP, it will be available as a pecl
extension. We need a strong signal about "don't use this dead cow",
and I think, moving it to pecl is such a signal.
Remi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlTQf2kACgkQYUppBSnxahhnhwCeIsgARB8lYW3D6bfGufbgEydi
fkoAoPfs69rx5gQlBN/ev+YDNWYxQaKd
=KviN
-----END PGP SIGNATURE
Hi Adam,
thanks for the explanations.
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.To explain my -1s:
- ext/imap and ext/mcrypt: while I realise that the underlying
libraries are dead, these extensions are too widely used to straight up
remove them, I fear — we don't have obvious alternatives with simple
enough APIs that we can push users towards. I'd strongly support and
encourage a reimplementation of these extensions (in C or PHP) around
something supported if someone was able to step up and do the work,
otherwise yes, I'll pitch in to do the minimal work to port these to 7.0
if required.
For ext/imap I can point to this old thread:
http://grokbase.com/t/php/php-internals/141zh29xs2/ext-imap-bye-bye-in-php-5-6
And at list this one living native PHP implementation
https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and
more library links in the older thread link above).
With ext/mcrypt there are also libs, I can point at least to this one
https://github.com/phpseclib/phpseclib
which was available even before PHP5.3 i think. Interestingly it can rely
on ext/mcrypt if available, otherwise it uses native PHP implementations.
Though note that those both are already ported, they landed in the RFC
exactly because of the dead dependency libraries.
I can just enclose myself to the reimlementation/surrogate layer idea.
Actually that would make sense also for the ext/regex which was voted to
be removed in another RFC. Otherwise, i'd rather advise users to use the
native PHP implementations.
- ext/pdo_dblib: ODBC is almost always the better way of interfacing
with SQL Server, but I don't think keeping this one around is doing anyone
much harm (as opposed to ext/mssql, which we should kill with fire for the
same reasons as ext/mysql).
There's also the sqlsrv extension
http://www.microsoft.com/en-us/download/details.aspx?id=20098 . I had no
chance to check ext/pdo_dblib but it's stated as not ported yet on the
PHPNG wiki page.
Abstentions:
- sapi/apache2filter: I wonder if someone would step up for that one
if we advertised more widely, given I believe that it is in actual use.
Unlike most of the other SAPIs, which are obviously dead, I'd
like to give this one a bit more time before the 7.0 feature freeze.
No movement on this so far in the PHP7 direction. Nobody is porting it,
nobody is asking for that.
- sapi/milter: I'm at least passingly familiar with almost all of the
Web servers in the list, but I know nothing about the environments
this SAPI is used in. Can someone who is familiar with it describe the pros
and cons to dropping it?
It's a very exotic thing. As mentioned in the RFC, with this you can hook
into the MTA process. But the PHP script is invoked fromwithin the MTA.
- ext/sybase_ct: does PDO (via dblib and/or ODBC) cover this
functionality adequately? I feel that I know enough to vote on SQL Server
related topics, but haven't looked at actual Sybase for years.
Basically the same as apache2filter - no movement on this towards PHP7.
Nobody is porting it, nobody is asking for that. If there are no constant
maintainers for this, IMHO porting it once which is doable, won't bring
anything good but tons of subtle bugs. Porting it once without real
maintanance and usage, just because we want to have "sybase" in, i mean.
I'm really curious about the stats after this RFC, which extensions/sapis
turned out to have found a new home and maintanance somewhere like PECL :)
Regards
Anatol
Hi!
And at list this one living native PHP implementation
https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and
more library links in the older thread link above).
This is part of Horde with 9 listed dependencies and 9 suggested ones,
and probably also sub-dependencies. It is much less convenient than
having imap right here when you run PHP. And looks like on top of that
it lists PHP 7 as not supported.
I'm sure there are other imap implementations, but I wouldn't be that
quick in throwing out one that a lot of people may use.
Stas Malyshev
smalyshev@gmail.com
Hi!
And at list this one living native PHP implementation
https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and
more library links in the older thread link above).This is part of Horde with 9 listed dependencies and 9 suggested ones,
and probably also sub-dependencies. It is much less convenient than
having imap right here when you run PHP. And looks like on top of that
it lists PHP 7 as not supported.
I'm sure there are other imap implementations, but I wouldn't be that
quick in throwing out one that a lot of people may use.
Roundcube imap cleint has many users, other mail libraries are getting a
lot of traction. It is not like our users do not move away already. For two
reasons, compatibly first (many bugs in imap using c-client) and also
because c-client is less and less available by default on many systems.
Hi Stas,
Hi!
And at list this one living native PHP implementation
https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and
more library links in the older thread link above).This is part of Horde with 9 listed dependencies and 9 suggested ones,
and probably also sub-dependencies. It is much less convenient than having
imap right here when you run PHP. And looks like on top of that it lists
PHP 7 as not supported.
I'm sure there are other imap implementations, but I wouldn't be that
quick in throwing out one that a lot of people may use. --
Stas Malyshev
smalyshev@gmail.com
Horde is being developed by a some ISP, so it's mostlikely gonna support
PHP7, even if not already. But this is actually what one can say regarding
PHP7 compatibility with any scripts at the current stage.
For security tickets - there are still some on mitre, NVD and others.
The point with ext/imap being available "now and here" instead of the
userland implementation is of course good. However removing it has the
same reasons like f.e. removing ext/regex or Apache 1.x SAPI. Letting it
be there, unmaintained, is kinda of a black hole. And every day it grows.
That's why my point is rather - link to some userland implementation
instead of shipping "worky" stuff in the unknown security state. Same
actually for mcrypt. Probably the same motivation can be attributed to the
unavailability of libc-client and mcrypt in RHEL6.
Regards
Anatol
Zitat von Anatol Belski anatol.php@belski.net:
Hi Stas,
Hi!
And at list this one living native PHP implementation
https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and
more library links in the older thread link above).This is part of Horde with 9 listed dependencies and 9 suggested ones,
and probably also sub-dependencies. It is much less convenient than having
imap right here when you run PHP. And looks like on top of that it lists
PHP 7 as not supported.
I'm sure there are other imap implementations, but I wouldn't be that
quick in throwing out one that a lot of people may use. --
Stas Malyshev
smalyshev@gmail.comHorde is being developed by a some ISP, so it's mostlikely gonna support
PHP7, even if not already. But this is actually what one can say regarding
PHP7 compatibility with any scripts at the current stage.
FWIW Horde is an open source project and not developed by any ISP.
Furthermore we're actively testing against PHP 7 and already detected
(and reported) a few bugs an regressions in master.
Not that this matters for this discussion, just for completeness.
For security tickets - there are still some on mitre, NVD and others.
The point with ext/imap being available "now and here" instead of the
userland implementation is of course good. However removing it has the
same reasons like f.e. removing ext/regex or Apache 1.x SAPI. Letting it
be there, unmaintained, is kinda of a black hole. And every day it grows.That's why my point is rather - link to some userland implementation
instead of shipping "worky" stuff in the unknown security state. Same
actually for mcrypt. Probably the same motivation can be attributed to the
unavailability of libc-client and mcrypt in RHEL6.Regards
Anatol
--
--
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject
Hi Jan,
Zitat von Anatol Belski anatol.php@belski.net:
Hi Stas,
Hi!
And at list this one living native PHP implementation
https://github.com/horde/horde/tree/master/framework/Imap_Client/
(and
more library links in the older thread link above).This is part of Horde with 9 listed dependencies and 9 suggested
ones, and probably also sub-dependencies. It is much less convenient
than having imap right here when you run PHP. And looks like on top of
that it lists PHP 7 as not supported.
I'm sure there are other imap implementations, but I wouldn't be that
quick in throwing out one that a lot of people may use. -- Stas
Malyshev
smalyshev@gmail.comHorde is being developed by a some ISP, so it's mostlikely gonna
support PHP7, even if not already. But this is actually what one can say
regarding PHP7 compatibility with any scripts at the current stage.FWIW Horde is an open source project and not developed by any ISP.
Furthermore we're actively testing against PHP 7 and already detected
(and reported) a few bugs an regressions in master.
Not that this matters for this discussion, just for completeness.
Yeah, thanks for extending this. I don't follow this project closely, but
have read the ISP part here http://dev.horde.org/imap_client/ . If the
IMAP client is not being funded but them anymore, heh ... the project
itself is for popular enough to take that.
Regards
Anatol
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.To explain my -1s:
- ext/imap and ext/mcrypt: while I realise that the underlying
libraries are dead, these extensions are too widely used to straight
up remove them, I fear — we don't have obvious alternatives with
simple enough APIs that we can push users towards. I'd strongly
support and encourage a reimplementation of these extensions (in C or
PHP) around something supported if someone was able to step up and do
the work, otherwise yes, I'll pitch in to do the minimal work to port
these to 7.0 if required.
We have plenty of alternative implemented in php, supporting way more
things that ext/IMAP ever did.
However I have a hard time to understand your argument.
We keep discussing how to improve security, make php safer by default, etc.
But for IMAP, you basically open the door with a big shield saying "come
in, we have free cooking and you can do almost all you want inside via this
door". This is insane. If it was only up to me I would kick it out of core
right now due to the critical issue it has.
Mcrypt is only a time bomb. It will be the same pretty soon.
Hi!
We keep discussing how to improve security, make php safer by default, etc.
But for IMAP, you basically open the door with a big shield saying "come
in, we have free cooking and you can do almost all you want inside via this
door". This is insane. If it was only up to me I would kick it out of core
right now due to the critical issue it has.
Which critical issue? I see no security issues listed in the bug DB for
imap.
--
Stas Malyshev
smalyshev@gmail.com
Hi!
I am kind of surprised that RFC about removing whole extensions has
"Backward Incompatible Changes" listed as "None". Really? No BC impact
whatsoever by removing imap and mcrypt? Literally nobody ever anywhere
is using it?
- ext/imap and ext/mcrypt: while I realise that the underlying
libraries are dead, these extensions are too widely used to straight
up remove them, I fear — we don't have obvious alternatives with
simple enough APIs that we can push users towards. I'd strongly
support and encourage a reimplementation of these extensions (in C or
PHP) around something supported if someone was able to step up and do
the work, otherwise yes, I'll pitch in to do the minimal work to port
these to 7.0 if required.
IIRC imap is working with PHP 7 and passes the tests on CI currently.
mcrypt seems to be enabled on CI too. So what is needed for them for 7.0?
--
Stas Malyshev
smalyshev@gmail.com
Hi!
I am kind of surprised that RFC about removing whole extensions has
"Backward Incompatible Changes" listed as "None". Really? No BC impact
whatsoever by removing imap and mcrypt? Literally nobody ever anywhere
is using it?
- ext/imap and ext/mcrypt: while I realise that the underlying
libraries are dead, these extensions are too widely used to straight
up remove them, I fear — we don't have obvious alternatives with
simple enough APIs that we can push users towards. I'd strongly
support and encourage a reimplementation of these extensions (in C or
PHP) around something supported if someone was able to step up and do
the work, otherwise yes, I'll pitch in to do the minimal work to port
these to 7.0 if required.IIRC imap is working with PHP 7 and passes the tests on CI currently.
mcrypt seems to be enabled on CI too. So what is needed for them for 7.0?
Both extensions are relatively thin wrappers around the respective
libraries. C-client for IMAP and libmcrypt for mcrypt.
Libmcrypt is a dead cow but not much of a threat for now. On the other hand
cclient is dangerous, it should have been removed long time ago already.
Cheers,
Pierre
Hi!
Libmcrypt is a dead cow but not much of a threat for now. On the other
hand cclient is dangerous, it should have been removed long time ago
already.
I'm not sure - what is the dangerous part? Are you referring to some
published CVEs or other reports? Then it would be useful to list them
here and on the RFC.
--
Stas Malyshev
smalyshev@gmail.com
Hi!
Libmcrypt is a dead cow but not much of a threat for now. On the other
hand cclient is dangerous, it should have been removed long time ago
already.I'm not sure - what is the dangerous part? Are you referring to some
published CVEs or other reports? Then it would be useful to list them
here and on the RFC.
I have to dig back (or may be in the last threads where we discussed
that). I will try to to post them here (RFC is in voting phase so no
edition) asap.
However, I totally fail to understand your reasoning. We know both
libraries are dead. ext/Imap is almost not used anymore by any major
tool relying on imap, Which appealing reasons do you have to force us
to have to maintain them for the next decade?
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi!
However, I totally fail to understand your reasoning. We know both
libraries are dead. ext/Imap is almost not used anymore by any major
What you mean by "major tool relying on imap"? I've used ext/imap
multiple times in the past, and I know others do too. Of course, there
are different libraries, so what - there are also libraries that support
HTTP or JSON, that's not the reason to remove HTTP or JSON support from
PHP.
tool relying on imap, Which appealing reasons do you have to force us
to have to maintain them for the next decade?
The same reason as for other things - it is useful and being used. If
you have reasons why not, I'm fine with considering them, but so far it
has been a bit vague. The fact that the library is not updated doesn't
mean it doesn't work. If it doesn't work - fine, let's see where it
doesn't work and decide then.
Stas Malyshev
smalyshev@gmail.com
Hi!
However, I totally fail to understand your reasoning. We know both
libraries are dead. ext/Imap is almost not used anymore by any majorWhat you mean by "major tool relying on imap"? I've used ext/imap
multiple times in the past, and I know others do too. Of course, there
are different libraries, so what - there are also libraries that support
HTTP or JSON, that's not the reason to remove HTTP or JSON support from
PHP.tool relying on imap, Which appealing reasons do you have to force us
to have to maintain them for the next decade?The same reason as for other things - it is useful and being used. If
you have reasons why not, I'm fine with considering them, but so far it
has been a bit vague. The fact that the library is not updated doesn't
mean it doesn't work. If it doesn't work - fine, let's see where it
doesn't work and decide then.
ftp://ftp.cac.washington.edu/imap
last release: 7/23/11
Now, considering its status (read: it is dead since 4 years), the way
it works (you know it kills the process on some error right? f.e.)
along other bugs (check the imap various support questions etc), and
you still all good to keep it around for the next decade? Fine. It is
in voting, so let see the results and move on. I however consider this
as an extremely bad decision. But I do not care enough to battle it to
death. Waste of time to argue about that.
--
Pierre
@pierrejoye | http://www.libgd.org
"Pierre Joye" wrote in message
news:CAEZPtU6au_Fi2bW=E2kiQLErq4h97VhU8NkL-Z9KatLsteFaRQ@mail.gmail.com...
On Wed, Feb 4, 2015 at 2:09 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:Hi!
Libmcrypt is a dead cow but not much of a threat for now. On the other
hand cclient is dangerous, it should have been removed long time ago
already.I'm not sure - what is the dangerous part? Are you referring to some
published CVEs or other reports? Then it would be useful to list them
here and on the RFC.I have to dig back (or may be in the last threads where we discussed
that). I will try to to post them here (RFC is in voting phase so no
edition) asap.However, I totally fail to understand your reasoning. We know both
libraries are dead. ext/Imap is almost not used anymore
Excuse me, but I use ext/imap quite extensively, and I would be most upset
if you dropped it without providing an alternative.
I would also be upset if you dropped it without ever it ever being marked as
deprecated.
--
Tony Marston
Hi Tony,
"Pierre Joye" wrote in message
news:CAEZPtU6au_Fi2bW=E2kiQLErq4h97VhU8NkL-Z9KatLsteFaRQ@mail.gmail.com...On Wed, Feb 4, 2015 at 2:09 PM, Stanislav Malyshev
smalyshev@gmail.com
wrote:Hi!
Libmcrypt is a dead cow but not much of a threat for now. On the
other hand cclient is dangerous, it should have been removed long
time ago already.I'm not sure - what is the dangerous part? Are you referring to some
published CVEs or other reports? Then it would be useful to list them
here and on the RFC.I have to dig back (or may be in the last threads where we discussed
that). I will try to to post them here (RFC is in voting phase so no
edition) asap.However, I totally fail to understand your reasoning. We know both
libraries are dead. ext/Imap is almost not used anymoreExcuse me, but I use ext/imap quite extensively, and I would be most
upset if you dropped it without providing an alternative.I would also be upset if you dropped it without ever it ever being marked
as deprecated.
Not like that PECL would be dropped, too :)
However you're right, those was not deprecated, just repeatedly discussed
in the past.
Regards
Anatol
"Anatol Belski" in php.internals (Mon, 2 Feb 2015 20:11:20 +0100):
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately.
ext/ereg needs a fix before it can be moved to PECL. The TS build
--with-ereg=shared currently fails:
Creating library C:\php-sdk\php70dev\Release_TS\php_ereg.lib and
object C:\php-sdk\php70dev\Release_TS\php_ereg.exp
ereg.obj : error LNK2001: unresolved external symbol __tsrm_ls_cache
C:\php-sdk\php70dev\Release_TS\php_ereg.dll : fatal error LNK1120: 1
unresolved externals
Jan
Le 02/02/2015 20:11, Anatol Belski a écrit :
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.
Hi,
After discussing this RFC with other people at AFUP (we weren't that
many to participate in this discussion -- which probably indicates not
many of us care about keeping those), it seems we would be:
- +1 to remove all SAPIs listed in this RFC
- +1 to remove ext/imap and ext/mcrypt -- some of us would have
preferred keeping those, but a new major version feels like the right
time to drop them, if the underlying libraries aren't maintained anymore. - +1 to remove ext/mssql and ext/sybase_ct
- and +0 for ext/pdo_dblib -- we didn't reach a consensus on that one.
Thanks
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
Just a quick side one, there's no way to make compatible calls from mcrypt
to openssl using "rijndael-192" and "rijndael-256" ciphers, a compatibility
layer is almost impossible. Only AES-128/192/256 (which variants of
"rijndael-128") are possible on both extensions.
On Mon, Feb 9, 2015 at 6:47 PM, Pascal MARTIN, AFUP <
mailing@pascal-martin.fr> wrote:
Le 02/02/2015 20:11, Anatol Belski a écrit :
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.Hi,
After discussing this RFC with other people at AFUP (we weren't that many
to participate in this discussion -- which probably indicates not many of
us care about keeping those), it seems we would be:
- +1 to remove all SAPIs listed in this RFC
- +1 to remove ext/imap and ext/mcrypt -- some of us would have preferred
keeping those, but a new major version feels like the right time to drop
them, if the underlying libraries aren't maintained anymore.- +1 to remove ext/mssql and ext/sybase_ct
- and +0 for ext/pdo_dblib -- we didn't reach a consensus on that one.
Thanks
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/