Re: [RFC] Libsodium - Discussion

From: 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/

« previous php.internals (#93675) next »