Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90262
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKws9z248Kj=0qTLPZik0Ki1_zGPq+4fr6HQi_keeVCso1S4eQ@mail.gmail.com>
References: <CAKws9z1g24rD=t92+9xKtO=3PuwQ3_N=L36gmVMqCC84CoqipQ@mail.gmail.com>
	<CAEZPtU7-Lk=jGsTQgRZOvBpcPPgdX3V-23=3_k9CXbmxU77V1A@mail.gmail.com>
	<CAKws9z248Kj=0qTLPZik0Ki1_zGPq+4fr6HQi_keeVCso1S4eQ@mail.gmail.com>
Date: Thu, 7 Jan 2016 23:24:15 +0700
Message-ID: <CAEZPtU7NpPWn0MsXjbFw9gNvRxm98XkHFk=RvQ1v0hRqcdGS3w@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Libsodium
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Jan 7, 2016 at 11:11 PM, Scott Arciszewski <scott@paragonie.com> wrote:
> On Thu, Jan 7, 2016 at 10:51 AM, Pierre Joye <pierre.php@gmail.com> wrote:
>> HI Scott,
>>
>> On Thu, Jan 7, 2016 at 8:26 PM, Scott Arciszewski <scott@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