On Sat, Mar 19, 2016 at 4:30 AM, Fleshgrinder <p...@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 should > 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 >= 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/>
