Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91788
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain paragonie.com designates 209.85.218.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <56ED0E3C.3020601@fleshgrinder.com>
References: <CAKws9z2e+GvX9gDJLPqTwio=Sr8i=0yQoCWVeyzvLh5Es24Kpg@mail.gmail.com>
	<CAGa2bXaQaBUi=C=MzhQYYznqRGJ06gR7oE+0nvuT6EKL6hN0gA@mail.gmail.com>
	<56E99E97.2050102@fleshgrinder.com>
	<CAGa2bXZYeTf7Hz5Doq+xf_vtM6=jxojx9SZb4gKMKaZKmvvMmQ@mail.gmail.com>
	<56EC5F02.60105@fleshgrinder.com>
	<CAFMT4NpM_MoJFFmP_-5MfT1DDvGznVF502m1ihjQtXzoqxc0pQ@mail.gmail.com>
	<CAFMT4NrvvhxmkkasPp4D54xp47ks4uhRCjG6RowXfJauyKxMPA@mail.gmail.com>
	<56ED0E3C.3020601@fleshgrinder.com>
Date: Sun, 20 Mar 2016 12:55:04 -0400
Message-ID: <CAKws9z0=eGYhZqyqhe+9Qr3KHY0MKsnqsaEBTneEeev3e-wqvA@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113a3c867e7c2d052e7dd7c9
Subject: Re: [PHP-DEV] [RFC] Libsodium (bump)
From: scott@paragonie.com (Scott Arciszewski)

--001a113a3c867e7c2d052e7dd7c9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 19, 2016 at 4:30 AM, Fleshgrinder <php@fleshgrinder.com> wrote:

> On 3/18/2016 9:56 PM, Levi Morrison wrote:
> >> At least that's not what it says in the docs.
> >
> > I  meant: at least according to the docs:
> > http://php.net/manual/en/language.namespaces.rationale.php
> >
> >> Namespace names PHP and php, and compound names starting with these
> names (like PHP\Classes) are reserved for internal language use and shoul=
d
> not be used in the userspace code.
> >
>
> Okay, I did not know that. However, right now all internal classes and
> functions are in *\* and that is also what the coding standards
> prescribe. My point being (and was) that this system works well, so why
> change it now shortly after a new major version. Changing all old code
> would result in an unbelievable breaking change, even with a new major
> version, without any real value. Yes, I am saying that although I am
> usually totally in favor of changing things to the better. I simply do
> not see *any* benefit here.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>
I'm 99% sure that the plan is to go with sodium_* since the change isn't
/that/ painful. (Creating a polyfill for code written against the PHP
extension is trivial.)

While I'd love to break new ground with this (the first extension to
actually use the reserved namespace), I'm concerned this would just create
a lot of pointless bikeshedding arguments. The goal here isn't to be
totally avant garde and break exciting new ground (even if the plot is
already allocated for "future development").

The goal here (for me, anyway) is to make cryptography in PHP boring: It
should be simply secure (with a security level >=3D 2^100 bits for all
meaningful metrics), as side-channel resistant as possible, and intuitive
for non-cryptographers to use properly. I want to see PHP get to where it's
easier to do the secure thing than to do the insecure thing. The password
hashing API in 5.5 was the first great leap towards this goal. Adding
CSPRNG functions in PHP 7 that throws an Exception when PHP can't access
the kernel's CSPRNG moved us further in the right direction.

Deprecating libmcrypt and introducing libsodium is, to me, the next logical
step towards that goal.

Until that happens, PHP developers will be given more than enough rope to
hang themselves (and the company they work for) with their fumbled
cryptography engineering. Let's take away the noose and give everyone a
safety net.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>=E2=80=8B

--001a113a3c867e7c2d052e7dd7c9--