mycrypt was abandoned by its developers in 2007. The package in Debian is
from 2009. It has been removed from RHEL.
This is already unacceptable. But it would be an insult to the idea of
"security" to include mcrypt in PHP 7.
The vote to remove mcrypt is at present tied roughly 13:13. If you have a
vote and haven't used it yet, I urge you to consider doing so. Voting ends
tomorrow 2015-02-09 at 23:00 CET
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extmcrypt
Tom Worster fsb@thefsb.org schreef op 8 februari 2015 15:38:15 GMT+00:00:
mycrypt was abandoned by its developers in 2007. The package in Debian
is
from 2009. It has been removed from RHEL.This is already unacceptable. But it would be an insult to the idea of
"security" to include mcrypt in PHP 7.The vote to remove mcrypt is at present tied roughly 13:13. If you have
a
vote and haven't used it yet, I urge you to consider doing so. Voting
ends
tomorrow 2015-02-09 at 23:00 CEThttps://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extmcrypt
Btw, I only voted no because I don't think we should just remove it. A reimplementation of its APIs on top of eg. Open SSL makes sense. And that I'd vote yes for.
Calling for a random deletion is misguided.
Remember that just removing quite often used APIs doesn't help anybody. It is not unlikely that devs would rather rip out the encryption as a quick fix, than porting it to quite awful other APIs, or perhaps even a really slow PHP based implementation.
cheers,
Derick - mcrypt extension author
Hi Derick,
Btw, I only voted no because I don't think we should just remove it. A
reimplementation of its APIs on top of eg. Open SSL makes sense. And that
I'd vote yes for.
This idea makes me nervous. It doesn't sound at all easy and will take a
lot of time and effort. Commitment to maintaining a security lib over long
term is a big deal.
Remember that just removing quite often used APIs doesn't help anybody.
It is not unlikely that devs would rather rip out the encryption as a
quick fix, than porting it to quite awful other APIs, or perhaps even a
really slow PHP based implementation.
I actually think that it helps users if PHP 7 moves mycrypt to PECL. The
developers' quick fix is to continue to use mcrypt. In doing so they
should encounter the documentation with scary warning about its long
abandoned status.
I'm concerned that a lot of devs relying on mcrypt are not aware of its
status and/or what it means. This move would allow them to continue to use
mcrypt while making it clear that its time to plan for an alternative.
Tom
Hi!
Btw, I only voted no because I don't think we should just remove it. A
reimplementation of its APIs on top of eg. Open SSL makes sense. And that
I'd vote yes for.This idea makes me nervous. It doesn't sound at all easy and will take a
lot of time and effort. Commitment to maintaining a security lib over long
term is a big deal.
The better alternative you proposing is having no mcrypt extension at
all in core. Which means the users have three choices:
- Rewrite all their code to a different API (with accompanying costs in
development, QA, stability, maintenance of code base now having two
APIs, etc.) - Do not upgrade to PHP 7
- Use the same extension from PECL
Option 1 however is very expensive, so it is unlikely most of the users
will choose it.
Both options 2 and 3 make the security situation for an average user
worse, as not upgrading means eventually falling out of supported
versions - and we're doing very bad in this regard, over 46% of the
users run EOLed versions now and less than 1% run current stable - and
running PECL one means most core devs will pay next to zero attention to
it.
--
Stas Malyshev
smalyshev@gmail.com
The better alternative you proposing is having no mcrypt extension at
all in core. Which means the users have three choices:
- Rewrite all their code to a different API (with accompanying costs in
development, QA, stability, maintenance of code base now having two
APIs, etc.)- Do not upgrade to PHP 7
- Use the same extension from PECL
Option 1 however is very expensive, so it is unlikely most of the users
will choose it.Both options 2 and 3 make the security situation for an average user
worse, as not upgrading means eventually falling out of supported
versions - and we're doing very bad in this regard, over 46% of the
users run EOLed versions now and less than 1% run current stable - and
running PECL one means most core devs will pay next to zero attention to
it.
As a PHP user, I have no interest in running the latest release. I'll
stay on 5.5 until the next LTS is mature. I know a lot of PHP users who
have a similar attitude: it is sufficient to be on a supported version.
People are scared of the bleeding edge and I think that goes a long way
to explaining the 1%.
Trying to improve these numbers by bringing along a crypto lib that's
been abandoned 8 years ago just doesn't strike me as either justified
or plausible. mcrypt is not the difference that makes conservatives like
me jump onto the latest release. Nor is it going to help the 43%, which,
I imagine, represents apps that aren't ever going to see further
development and lazy hosting.
I also disagree with your analysis. There is simply no hurry to get onto
PHP 7, so I have time to get rid of mycrypt, something I must do ASAP
regardless whether it is in PHP 7 or not.
In any case, I'll stop discussing this now. The vote outcome won't
change in the next 6.5 hours.
Tom