Make Libsodium a Core Extension

PHP 7 has only been out for weeks, and already we’re at version 7.0.2. Bug fixes, mainly, but that doesn’t stop the awesome machine that PHP internals has become from chugging along and planning new major features, too. Among others, we’ve got several very interesting RFCs: Mcrypt viking funeral Short and to the point, this RFC proposes the immediate deprecation of the mcrypt extension. “But why?”, you may wonder. “Don’t major frameworks and libraries depend on it still?” - and yes, you’d be right. Turns out, everyone’s doing it wrong by still relying on it. The mcrypt extension needs to go, and a viable replacement is libsodium. Get libsodium into core Apropos libsodium, the same RFC author proposes it be added to the core of PHP. It’s a very secure library relied on by huge companies and with large backers, so it only makes sense. Security by default is a good idea, particularly in an ecosystem as damaged by outdated material as PHP’s is. PHP crypto With the above requirements firmly established, this RFC builds on them further by proposing the development of core crypto classes used for asymmetrical and symmetrical encryption, right in PHP’s core without the need to compile and install additional extensions. It would leverage support of openssl or libsodium, both of which are viable replacements for mcrypt. I personally think this is a fantastic idea, and I can think of many uses for these classes. Class friendship This RFC proposes the introduction of a new keyword: friend, to be used as use when usingtraits. Any “friended” class will then have access to protected and above (so not private) properties and methods of the class declaring the friend. Even skimming through the basic usage and the test example below it, I must admit I fail to see a possible use case for this that cannot already be solved without this apparent coupling-overhead. Perhaps someone can shed some light on the matter? Do it in the forum topic please! Code of Conduct Finally, and perhaps most controversially, Anthony Ferrara suggested the PHP project adopt a code of conduct - something of a trend that appeared in 2015 in several projects / programming languages. Much like any modern sensitive topic does, this RFC divided the community into those extremely against it and those extremely for it - there’s few who stand in the middle and just shrug. I’m on the “against” side, personally, but am willing to discuss it (and will do so in a personal blog post off of SitePoint) - this move has the potential to dramatically change the way contributions to the PHP core are made. What’s your stance on PHP adopting a CoC? Let us know in the forum? Oh, have you filled out our reader satisfaction survey yet? We’re looking for input on where we can do better and how, and every reply is read and analyzed - please give us your thoughts here!