Re: [RFC] Libsodium - Discussion
| From: | Marco Pivetta | Date: | Wed, 01 Jun 2016 13:46:45 +0000 |
| Subject: | Re: [RFC] Libsodium - Discussion | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-93675@lists.php.net to get a copy of this message | ||
On 1 June 2016 at 15:45, Scott Arciszewski <scott@paragonie.com> wrote:
> On Wed, Jun 1, 2016 at 6:48 AM, Marco Pivetta <ocramius@gmail.com> wrote:
>
>> Hey Scott,
>>
>> On 1 June 2016 at 09:49, Scott Arciszewski <scott@paragonie.com> wrote:
>>
>>> Hi PHP Internals Team,
>>>
>>> Let's begin discussing the prospect of adding libsodium as a core
>>> extension
>>> in PHP 7.1. I've updated the RFC to explain why this would be a good idea
>>> and the benefits it offers.
>>>
>>> https://wiki.php.net/rfc/libsodium
>>>
>>> If the subsequent discussion goes smoothly, I would like to open voting
>>> on
>>> June 15.
>>>
>>> Together, let's make PHP cryptography so safe that it becomes boring.
>>>
>>
>> First, thanks for providing better alternatives to crypto in PHP!
>>
>> I also agree with Remi on naming: let's avoid calling the extension
>>
libsodium.
>>
>> I have some concerns that are just about code quality, not about
>> functionality. Consider that I didn't look at the underlying library (and I
>> really care little about it, from a consumer perspective).
>>
>> 1. is there a particular reason why abbreviations are used? For
>> instance, why sodium_randombytes_buf() instead of
>> sodium_random_bytes_buffer()?
>> 2. from a naming perspective, I'd expect
>> sodium_randombytes_buf() to
>> give me a buffer of random bytes (probably as a stream), but it returns the
>> actual string of random bytes. Again: confusing naming
>> 3. can we avoid using "themed" naming? For example, instead of
>> sodium_crypto_secretbox(), it would be best to express what
>> it actually
>> does, like sodium_encrypt_and_sign(). While the naming may
>> be emerging
>> from lower layers, I still (like I did with other RFCs) disagree with
>> inheriting confusing naming. This will just cause users to look up the
>> naming up when reading or writing code, and ultimately add up to silly
>> bugs. I can already foresee that people will use the API incorrectly just
>> because of the naming.
>> 4. can't we just keep it namespaced under Sodium,
>> instead of adding
>> more stuff to the root level namespace? Does anyone have a reference to the
>> coding standards that would cause the rename?
>>
>> Cheers,
>>
>> Marco Pivetta
>>
>> http://twitter.com/Ocramius
>>
>> http://ocramius.github.com/
>>
>>
> I'd love to just keep the namespace personally
> (
> Ke
> eping \Sodium\foo() and \SODIUM\FOO means code I've written today will
> work in 7.1 for non-PECL users
> , and less work we thrust on Frank Denis)
>
> but it was previously expressed that doing so violates the coding standard.
> Changing to sodium_* would mean less bikeshedding and automatic "No"
> votes.
>
Weird... I guess we could add a subsection to the vote?
> As for the function names, that's what they were called in NaCl.
> https://nacl.cr.yp.to/secretbox.html
>
> I believe randombytes_buf() was named in a similar spirit to OpenBSD's
> arc4random_buf().
>
Yeh, that is software archaeology though, not software design ;-)
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/