php[architect] magazine has posted their latest issue, the July 2017 edition of the magazine - Safe at Speed:

“Safe at Speed” includes articles on:

• Setting up infrastructure from Zero to Cloud in One Hour With the Google Cloud by Robert Aboukhalil.
• Geogriana Gligor writes on Smart, Scalable Content Distribution.
• Brush up your front end skills with Modern JavaScript: Moving Beyond jQuery by Derek Binkley.
• Learn how and why we must of safety first when writing code in The Train Wreck: When Safety Is Discretionary by Ed Barnard .

The regular columns are all returning too including Community Corner and a new column from Chris Tankersley called "The Dev Lead Trenches". You can get more information about this latest issue, pick up a free article and get a copy of your own from the php|architect site.

On the SitePoint PHP blog Christopher Pitt is back with another interesting article, this time talking about two "delicious evils of PHP" - the eval and exec functionality.

I want to look at two PHP functions: eval and exec. They’re so often thrown under the sensible-developers-never-use-these bus that I sometimes wonder how many awesome applications we miss out on.

Like every other function in the standard library, these have their uses. They can be abused. Their danger lies in the amount of flexibility and power they offer even the most novice of developers. Let me show you some of the ways I’ve seen these used, and then we can talk about safety precautions and moderation.

He then talks about some of the "interesting" things you can do with these two pieces of functionality including:

• Dynamic Class Creation
• [Creating] Domain Specific Languages
• Parallelism (with exec)

He ends the post with some advice how to avoid issues with the topics he's mentioned and how to "stay safe" while still using these two dangerous pieces of functionality.

The Paragon Initiative blog has posted a new article showing you how to safely implement cryptography in any PHP-based application (or really just about any application) with the help of libsodium.

Why not {Mcrypt, OpenSSL, Bouncy Castle, KeyCzar, etc.}? These cryptography libraries are really building blocks that by and large must be used, with expert care, to build the interfaces you want developers to use. In most cases, libsodium is the interface you want developers to use. [...] By default, these libraries don't provide [authenticated encryption](https://tonyarcieri.com/all-the-crypto-code-youve-ever-written-is-probably-broken). Most of them force developers to use RSA (or ECDSA but certainly not EdDSA), which is [hard to get right](http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html) and for which [index calculus attacks are improving each year](https://events.ccc.de/congress/2014/Fahrplan/system/attachments/2501/original/20141227.pdf).

He goes on to talk about NaCI as a possible option (libsodium is from a fork of it) but points out that NaCI isn't as easily available as libsodium to non-C/Python developers. He shares a few reasons why he thinks "libsodium is so great" and a few reasons not to use it (mostly dealing with outside limitations, not technical ones). Finally he points you in the right direction to help you get started using libsodium for PHP as a PECL extension.

The Paragon Initiative blog has posted a guide to what they see as a way to safely generate random strings and integers in PHP applications.

Generating useful random data is a fairly common task for a developer to implement, but also one that developers rarely get right. [...] It's generally not okay to use a weak random number generator unless both of the following two conditions are met: the security of your application does not depend in any way on the value you generate being unpredictable or there is no requirement for each value to be unique (up to a reasonable probability).

He gives some examples of places where it's a must to use a "cryptographically secure pseudo-random number generator" including generating random passwords, encryption keys or IVs for data in CBC mode. The article goes on to talk about some of the problems that could come from using weak generators. It then gets into the process for generating random values and the use of the random_* functions in PHP (or using this polyfill) to more safely generate the numbers. Included is code showing the process and some advice around converting random bytes to both strings and integers.

NetTuts.com has posted the second part in their "When You're Hacked - WordPress" tutorial series today with this new article showing you how to stay safe once you've recovered from the initial attack.

n the first part of this series, we went through what to do when your website gets hacked. In this second part, we're going to learn about staying safe and being able to act quickly when another unpleasant incident happens.

They start by answering the overarching question everyone wants to know about WordPress (as it relates to security) - "is it safe?" They follow this with some recommendations to help keep your install safe including:

• Staying Up to Date
• Using Safe Plugins & Themes
• Using a Security-Related WordPress Plugin

Check out the rest of the article for the full list and a quick summary of each, some with links to the actual tools and plugins to help you protect your installation.

In this recent post to his blog Johannes Schlüter he talks about a way that he's come up with to test functionality that uses persistent connections (and an module he created to help).

In a few rare cases this is not what people like, for that PHP introduced "persistent connections" of different kinds. Testing those is a bit annoying as you have to configure a webserver and ensure to hit the same instance over the course of a test and then use a load generator, probably one which can detect a failure. Additionally by having a webserver in the game there is more code being executed, which might mean an additional source for trouble while debugging. An alternative might be using FastCGI, while that adds it's own issues for such a test. To solve this for myself I, some time ago, wrote a PHP SAPI module called pconn and pushed it to github.

The extension provides a way to emulate requests by executing a script multiple times automatically, making it easier to test things that require checking against multiple things simultaneously. While the built-in webserver (PHP 5.4) can be used to test some of these things too, Johannes' extension can also be compiled to help with testing of threading in applications as well.

On DevShed today, there's a new tutorial posted looking at two things that can cause headaches for PHP developers (especially when evaluating and comparing values) - nulls and empty strings.

Anyone who has programmed for any length of time has encountered the concepts of null and empty strings. They are not the same, and confusing the two can cause some serious problems. This article deals with these concepts in the context of PHP and MySQL.

They start with a bit of a quiz before getting into how to handle them correctly - making null "safe" and working with it correctly in a MySQL context. SQL statements and table structures are included for their examples.

On his blog, Mike Lively has posted a look at some of the work he's been doing on patches for the late static binding functionality to be included in PHP, including an example of the updates in action.

This weekend I wrapped up a few small tests and sent the patch in and it was subsequently pushed to php 5.3 and php 6.0. Now, this is not at all the way I wanted things to work, in all honesty I think the patch is pretty hokey but unfortunately nobody really spoke up in support of the changes I wanted to make to parent:: in regards to LSB.

His example shows how to override a static method and push that new method's execution to the parent class (in two ways - safe using forward_static_call and the not so safe calling itself with a parent:: override).

Andrei Zmievski has posted an encouraging note on his blog about the progress of PHP6 concerning the number of functions that have been correctly converted to support Unicode.

Well, PHP boys and girls, this feels like quite a milestone: 50% of the 3084 functions that are bundled with PHP 6 have been upgraded to support and work safely with Unicode.

He includes a small chart beside the post as well showing where things are currently at like the safe vs unsafe functions.

Andrei Zmievski has posted an encouraging note on his blog about the progress of PHP6 concerning the number of functions that have been correctly converted to support Unicode.

Well, PHP boys and girls, this feels like quite a milestone: 50% of the 3084 functions that are bundled with PHP 6 have been upgraded to support and work safely with Unicode.

He includes a small chart beside the post as well showing where things are currently at like the safe vs unsafe functions.