Replace mcrypt functionality with openssl

[cweagans]

OpenSSL supports more cryptographic algorithms than mcrypt, and is installed by default on most PHP installations. Many distros are now removing support for the mcrypt extension, and mcrypt itself is completely unmaintained.

[pitbulk]

@cweagans,
This toolkit requires mcrypt in order to encrypt / decrypt. We use a 3rd party software that requires it:
https://github.com/robrichards/xmlseclibs

I don't know if as you suggested it use can be replate by openssl, but you may ask this to the xmlseclibs maintainer.

btw, I saw your comments in that related post:
http://thefsb.tumblr.com/post/110639027905/custodians-of-php-vote-to-keep-a-crypto-lib

[cweagans]

Okay, I just assumed since it was required in this project's composer.json. I'll open an issue over at xmlseclibs. In the mean time, would #78 be okay?

[pitbulk]

Once xmlseclibs does not require it, I will remove the dependence, but right now we require it.
(right now we have xmlseclibs integrated, not installed as composer dependence).

[cweagans]

That seems....strange. Why is that the case? Wouldn't it be easier to add xmlseclibs as a composer dependency?

[pitbulk]

Yes, some of our customers don't use composer so they can just copy the lib folder and use it in their projects. That was the initial reason.

[amochohan]

Apologies re-raising such an old issue, but with PHP 7.1 now released, mycrpt has (thankfully) been deprecated. It will be removed entirely in PHP 7.2 later this year.

Mcrypt is abandonware and has been for around a decade, so serious efforts should be made to remove support for it completely in this package.

I've taken a look at the xmlseclibs dependency which looks like it has been updated to remove the mcrypt dependency in PR101.

[Hikariii]

@cweagans and @pitbulk, agreeing with @amochohan here to re-open this issue.
Mcrypt is abandonware:
http://php.net/manual/en/migration71.deprecated.php
I don't think we should put our money on a dead horse so to speak.

[pitbulk]

As soon as xmlseclibs offers an alternative we will deprecate mcrypt here.

[ghost]

@pitbulk - I've asked a question to xmlseclibs (shown in the reference above) but all is silent...

So, I would greatly appreciate finding out if there has from a php-saml perspective been any change to status and proposed strategy for dealing with mcrypt deprecation since your comment in February?

thanks so much!

[pitbulk]

@rickyrocker

I created 2 branches:

• remove-mcrypt Current php-saml without mcrypt dependency
• 3.0.0 The future php-saml several improvements

[ghost]

@pitbulk - thanks so much for letting me know!

Just so I'm completely clear, my understandings of what you're saying above are as follows:

1. https://github.com/onelogin/php-saml/tree/remove_mcrypt has no reliance on the mcrypt library, and I can safely upgrade to it right now if I want to get rid of mcrypt from our space.

2. https://github.com/onelogin/php-saml/tree/3.0.0 is the main development path but it still has dependency on mcrypt which will be removed at "some" point in the future.

3. If I upgrade to remove-mcrypt now, I will at some point need to migrate to the 3.x branch as remove-mcrypt is a temporary filler branch only.

I would greatly appreciate it if you could confirm whether the above understandings are correct. Thanks again!!

[pitbulk]

1. I applied the patch to remove mcrypt dependency on the code I hosted from robrichards/xmlseclibs
   and I plan time to time to merge changes from master branch on that branch... but don't make an official release for this branch... official release will be related to the 3.0.0 branch.

2. 3.0.0 can be also used... it rely on robrichards/xmlseclibs 3.0.0 that removed mcrypt dependency

3. It will take time to implement all the improvements we want for 3.0.0 branch

[ghost]

@pitbulk - Man your responses are too good - thank you again!

One last question - I promise! :)

We have a production SAML environment that has 3 primary requirements::

1. It should be stable (we don't currently need any new functionality)
2. It should support encryption
3. It should support PHP 7.1 without any deprecation warnings (ie. no mcrypt)

Against that backdrop it seems to me from your explanation that either 3.0.0 or remove_mcrypt would work.

If my assessment is correct, then my inclination is to go with 3.0.0 as it is the master branch.

Would you agree with this approach or do you think remove_mcrypt would be a better option?

[pitbulk]

We plan to implement prs-7 on 3.0.0 so code will be quite different than the current available (but we may maintain main API methods), but no idea when I gonna have the required time to make this happen.. remove_mcrypt is simply the current branch without mcrypt dependency so will be easier to keep it updated from master (2.X)

I have no reply to your question...

[ghost]

remove_mcrypt it is then as we need to move on this pretty snappily :)

Thank you again for your great responses @pitbulk - I really do appreciate it tremendously

And also of course for providing such a great SAML implementation :)