On Thu, Jan 7, 2016 at 11:11 PM, Scott Arciszewski <sc...@paragonie.com> wrote: > On Thu, Jan 7, 2016 at 10:51 AM, Pierre Joye <pierre....@gmail.com> wrote: >> HI Scott, >> >> On Thu, Jan 7, 2016 at 8:26 PM, Scott Arciszewski <sc...@paragonie.com> >> wrote: >>> Hi everyone, >>> >>> I've updated the RFC to make libsodium a core PHP extension in 7.1, to >>> include references to the online documentation. >>> >>> https://wiki.php.net/rfc/libsodium >>> >>> All new functions and classes would exist in the Sodium namespace. e.g. >>> >>> $ciphertext = \Sodium\crypto_box($message, $nonce, $keypair); >> >> As much as I like libsodium, yet another extension with yet another >> library in the core sounds like a risk to me, long term. I would >> rather prefer to focus on a larger effort to provide the necessary >> features in the most easiest way using new APIs or existing >> extensions, as you mentioned already in previous discussions and in >> this mail. That's why I won't be in favor of bundling this one. >> >>> This is part of an overall effort to improve PHP's cryptography; up >>> next will be the pluggable crypto API that supports multiple backends >>> (with a scope limited to openssl and libsodium at the time of release) >>> but always provide conservative defaults. Then I'd like to look at >>> deprecating ext/mcrypt back to PECL and add more hash functions to >>> ext/hash. >> >> This is definitely the way. Thanks for your great work :) >> >> Cheers, >> Pierre > > Hi Pierre, > >> As much as I like libsodium, yet another extension with yet another >> library in the core sounds like a risk to me, long term. I would >> rather prefer to focus on a larger effort to provide the necessary >> features in the most easiest way using new APIs or existing >> extensions, as you mentioned already in previous discussions and in >> this mail. That's why I won't be in favor of bundling this one. > > Even if we axe mcrypt and in with a net-gain of 0 extensions, you'd > see it as a risk?
Except that we already refused to kill mcrypt, and it is not like I did not try to convince us to kill it. Does your extension provide a compatibility layer? I may have missed that :) > ---------------- > > Let me state this clearly: I'm personally not going to bother pushing > for a pluggable crypto API if the only option is to use OpenSSL and > all its legacy cruft. I especially don't have lukewarm feelings > towards RSA or ECDSA, which are your only real options with it. > > I feel that it simply would not be a worthwhile use of my time to do > so. If Internals decides "no libsodium" but "yes pluggable crypto > API", you'll have to find someone else to spearhead it. Sorry, my point was not clear. I do like the concept of a pluggable crypto API. Very much. I said it before and I say it again. I love the concept and will do what I can to support it :) What I do not like too much is the addition of an extension with (relatively) low level functions for one specific library. It does not really matter how good is this specific library, I simply do not see such addition as a good strategic move. > And I've said everything that needs to be said about mcrypt when I > said, "Kill it with fire!" Now that we have random_bytes() there is > nothing redeemable about it. Full ack. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
