On Wed, Jun 1, 2016 at 9:46 AM, Marco Pivetta <ocram...@gmail.com> wrote:
> On 1 June 2016 at 15:45, Scott Arciszewski <sc...@paragonie.com> wrote: > >> On Wed, Jun 1, 2016 at 6:48 AM, Marco Pivetta <ocram...@gmail.com> wrote: >> >>> Hey Scott, >>> >>> On 1 June 2016 at 09:49, Scott Arciszewski <sc...@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/ > > I've added "proposed voting choices". 1. Adopt libsodium? 2. ...as-is? (Otherwise, prefix ahoy!) This is precisely the sort of thing that should be voted on rather than bikeshedded. :) Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com/>
