Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93668
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKws9z114YcHkDaXO3o-E0JuHR10WsPzyedeF_8Q=shHDziwug@mail.gmail.com>
References: <CAKws9z114YcHkDaXO3o-E0JuHR10WsPzyedeF_8Q=shHDziwug@mail.gmail.com>
Date: Wed, 1 Jun 2016 12:48:00 +0200
Message-ID: <CADyq6sKr_6qi4Fnk9+yxgCA5j_xF7B7vxq7HH5_nneax5bLf5A@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114245725b15ec0534353a6c
Subject: Re: [PHP-DEV] [RFC] Libsodium - Discussion
From: ocramius@gmail.com (Marco Pivetta)

--001a114245725b15ec0534353a6c
Content-Type: text/plain; charset=UTF-8

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/

--001a114245725b15ec0534353a6c--