Re: [RFC] Libsodium
| From: | Scott Arciszewski | Date: | Thu, 07 Jan 2016 15:31:59 +0000 |
| Subject: | Re: [RFC] Libsodium | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-90253@lists.php.net to get a copy of this message | ||
On Thu, Jan 7, 2016 at 10:20 AM, Bishop Bettini <bishop@php.net> wrote:
> On Thu, Jan 7, 2016 at 8:26 AM, Scott Arciszewski <scott@paragonie.com>
> wrote:
>>
>> 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);
>>
>> 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.
>
>
> +1. Only comment is on namespace: how about \Php\Ext\Sodium? I don't know
> if namespacing PHP engine components has been standardized, but I feel we
> should limit how often the engine consumes names in the global namespace.
> E.g, I could see a user wanting "Sodium" for an app name, but couldn't use
> it simultaneously with the libsodium extension.
Originally it was Sodium::function_name, but people complained.
I don't personally have a stake in this course of discussion. I'm fine
with almost anything, but the PECL extension, which has a "stable"
release, uses \Sodium\* already.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>