Encryption Routines and PHP 5.1+

20 years ago by Mark Evans — view source

unread

Hi All

I am sorry if this has been asked before... I have searched the
internals list and also many of the other php lists but couldnt find
any conclusive answer.

The question is, are there any plans to include integrated encryption
routines in the php core?

At the moment the optional mcrypt library is needed and this is often
not installed so a fall back is needed were the routines are written
in pure php.

Since the mcrypt library is released under the GPL and php under the
php 3.0 licence I guess the option to integrate the solutions isnt
available so the other option would be for php to include their own
encryption routines.

Is this planned or is this even an option?

Also as you can imagine trying to do asymmetrical encryption in pure
php isnt very efficient so if the above is planned would it at the
same time be possible to include so kind of asymmetrical routine such
as diffie-hellman or the like?

Many thanks for any response.

Regards

Mark

20 years ago by Derick Rethans — view source

unread

Since the mcrypt library is released under the GPL and php under the
php 3.0 licence I guess the option to integrate the solutions isnt
available so the other option would be for php to include their own
encryption routines.

libmcrypt is LGPL, not GPL - which allows it to bundled it with PHP.

Is this planned or is this even an option?

This is definitely not planned - we rather not bundle any library, and
definitely not an LGPL library.

Reinventing the wheel by providing encryption routines in PHP does not
make sense really. PHP is meant to be a glue to provide access to
libraries, and not meant to be reimplementing them.

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

20 years ago by Matthew Charles Kavanagh — view source

unread

(earlier message, sending to list)

Derick Rethans wrote:

This is definitely not planned - we rather not bundle any library, and
definitely not an LGPL library.

Reinventing the wheel by providing encryption routines in PHP does not
make sense really. PHP is meant to be a glue to provide access to
libraries, and not meant to be reimplementing them.

The issue in my mind is one of portability. It would be nice, as a
developer working in PHP, to be able to rely on functionality like
encryption (and other unrelated goodies) being available on Joe User's
$5/month webhost who don't go around installing fancy packages.

20 years ago by Adam Maccabee Trachtenberg — view source

unread

The issue in my mind is one of portability. It would be nice, as a
developer working in PHP, to be able to rely on functionality like
encryption (and other unrelated goodies) being available on Joe User's
$5/month webhost who don't go around installing fancy packages.

We know. However, right now encryption does rise to that level for
us.

First, this attitude isn't scalable. (i.e. should PHP bundle
everything? libxml2? MySQL? where is the line?)

Second, the whole point of libaries is that you shouldn't need to
bundle them with every package. We would prefer education instead of
working around the problem.

Third, there are all sorts of nasty export restrictions in some
countries w/r/t crypto and I don't want to get involved with that.

We've hashed this type of issue over many times. I can assure you, we
won't bundle crypt at this time. It's not worth debating,
really. Please don't continue asking as it will only annoy
people. Honestly. :)

-adam

--
adam@trachtenberg.com | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!

20 years ago by Derick Rethans — view source

unread

Derick Rethans wrote:

This is definitely not planned - we rather not bundle any library, and
definitely not an LGPL library.

Reinventing the wheel by providing encryption routines in PHP does not
make sense really. PHP is meant to be a glue to provide access to
libraries, and not meant to be reimplementing them.

The issue in my mind is one of portability. It would be nice, as a
developer working in PHP, to be able to rely on functionality like
encryption (and other unrelated goodies) being available on Joe User's
$5/month webhost who don't go around installing fancy packages.

Get a better webhost. If you want to use PHP's more advanced (and less
used) extensions you need to pick a better host.

And CC the mailinglist!

Derick

20 years ago by Matthew Charles Kavanagh — view source

unread

Derick Rethans wrote:

The issue in my mind is one of portability. It would be nice, as a
developer working in PHP, to be able to rely on functionality like
encryption (and other unrelated goodies) being available on Joe User's
$5/month webhost who don't go around installing fancy packages.

Get a better webhost. If you want to use PHP's more advanced (and less
used) extensions you need to pick a better host.

Perhaps you're not seeing my point, or perhaps you don't care about
users? I speak as a developer, not as some guy with a crap webhost, and
my concern is that I would like to write applications that many people
can run, not just those who take out a loan against their house to pay
for webhosting. Many other developers will feel the same way as me.

20 years ago by Christian Schneider — view source

unread

Matthew Charles Kavanagh wrote:

Perhaps you're not seeing my point, or perhaps you don't care about
users? I speak as a developer, not as some guy with a crap webhost, and

So according to you every single extension should be put bundled and
installed by default?
If not, then someone has to draw the line and decide which ones are
treated as "first class" and that's exactly what people (e.g. Derick)
are doing here: They decided against bundling libmcrypt.

I'm sure if there's a major uproar about an extension being mandatory
for the next killer application then they'll reconsider. But for now it
seems that encryption functionality a la mcrypt hasn't been in high
enough demand.

Chris

20 years ago by Matthew Charles Kavanagh — view source

unread

Christian Schneider wrote:

Matthew Charles Kavanagh wrote:

Perhaps you're not seeing my point, or perhaps you don't care about
users? I speak as a developer, not as some guy with a crap webhost, and

So according to you every single extension should be put bundled and
installed by default?
If not, then someone has to draw the line and decide which ones are
treated as "first class" and that's exactly what people (e.g. Derick)
are doing here: They decided against bundling libmcrypt.

I'm sure if there's a major uproar about an extension being mandatory
for the next killer application then they'll reconsider. But for now it
seems that encryption functionality a la mcrypt hasn't been in high
enough demand.

Chris

I'd think that this thread is a discussion about whether people actually
want mcrypt, and I think I have indicated my position :)

20 years ago by Derick Rethans — view source

unread

I'm sure if there's a major uproar about an extension being mandatory
for the next killer application then they'll reconsider. But for now it
seems that encryption functionality a la mcrypt hasn't been in high
enough demand.

Even if it was, I would be against bundling libraries. There are plenty
of reasons which I'm not going to rehash now (search the archives).

regards,
Derick

20 years ago by Derick Rethans — view source

unread

Perhaps you're not seeing my point, or perhaps you don't care about
users? I speak as a developer, not as some guy with a crap webhost, and
my concern is that I would like to write applications that many people
can run, not just those who take out a loan against their house to pay
for webhosting. Many other developers will feel the same way as me.

There are also developers who want to use Oracle, should we bundle
Oracle client libraries? There are also developers who want to use X,
should we bundle X' client libraries?

Often it's not even possible to bundle libraries (libmcrypt is one, as
it's LGPL - we do NOT want to get into GPL/LGPL mess again), in other
cases it's only very rarely used.

As a developer you have options:
a) make sure things that rely on things that are not enabled by default
are optional components of your application
b) make sure to re-implement things that are not available in PHP
c) tell your users to get a decent webhost - all decent ones will gladly
add a new extension

Make your choice.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org