Go PHP 7 - Our Commitment to Maintaining our Open Source Projects

We built numerous free and open source projects over the past year. Since the primary goal of most of these projects is to improve the security of the PHP ecosystem, it's important for us to publicly formalize our release cycle and help answer the question, "Which version should we use and why?"

General Policy Towards Our Software

With the exception of polyfill libraries (e.g. random_compat), we will only be providing support to current versions of PHP. This means the ones highlighted green or orange on this page.

Before anyone asks, we currently have no plans to make any exceptions to accommodate certain operating systems' policies regarding so-called "Long Term Support", as we do not have business agreements with any operating systems to continue supporting PHP versions that have reached End of Life in our open source projects.

If anything changes, we will update this paragraph at a later date.

Open Source Libraries

What follows applies to our open source projects on Github.

There will be two branches (though they're functionally identical right now):

Version 1.x - supports PHP 5 and PHP 7 projects

- supports PHP 5 and PHP 7 projects Version 2.x - only supports PHP 7 projects

We will cease development on version 1.x when PHP 5.6 is no longer supported by the PHP team. We will continue to develop and support version 2.x (and any future iterations) until we need to split it again.

Which Version of Anti-CSRF Should I Use?

If you need PHP 5 support, use version 1. Be aware that, in 2018, we will stop supporting version 1 completely.

If you don't need PHP 5 support, just use version 2.

Our policy here is identical to our policy towards Anti-CSRF. Use version 1.x if you require compatibility with PHP 5.x projects. Otherwise, we recommend using version 2.x so your projects don't get left behind when we stop supporting the version 1 branch.

Our policy here is identical to our policy towards Anti-CSRF. Use version 1.3.1+ if you require compatibility with PHP 5.x projects. Otherwise, we recommend using version 2.x so your projects don't get left behind when we stop supporting the version 1 branch.

Our policy here is identical to our policy towards Anti-CSRF. Use version 1.x if you require compatibility with PHP 5.x projects. Otherwise, we recommend using version 2.x so your projects don't get left behind when we stop supporting the version 1 branch.

We will be rewriting it to use defuse/php-encryption version 2.0.0 (once that's ready) and then releasing version 1.0.0, possibly in May. Soon after, we will release an EasyRSA 2.0.0 that only supports PHP 7 and uses scalar type declarations with strict typing.

We're no longer supporting the version 1 branch. If you can install PHP extensions, you should have no trouble upgrading to PHP 7. The simplicity and correctness offered by strict scalar type declarations in PHP 7 means greater confidence about the reliability and robustness of Halite 2.

If PHP 7.1 adopts libsodium, we will discuss a support cycle going forward, but what you can probably expect is that we'll rewrite a version 3 branch that uses the native sodium_* functions in PHP 7.1+ and maintain support for Halite 2.x until PHP 7.0 has reached end-of-life, then continue to support Halite 3 until we need to increase the major version again. This is just speculation, as we don't know what the future entails.

Recommendation: Use Halite 2.1.1 or newer, which requires PHP 7.

We will be releasing Password_Lock version 2 in the near future (it also depends on Defuse Security's PHP Encryption Library). Shortly afterwards, we will be releasing version 3 (which will be PHP 7-only and employ strict scalar type declarations internally).

Recommendation: Wait until version 2 comes out, then use it in projects where "supports PHP 5.x" is a requirement. Switch to version 3 (when it's available) if you can commit to only supporting PHP 7.0 and newer.

This is a polyfill library for a native PHP 7 feature; thus, the requirements and recommendations are a drastic departure from everything else on this list.

Recommendations at a Glance:

Developers: Use Version 2 in PHP 5 projects; don't bother adding it to PHP 7+ projects.

Library maintainers: Add ^1|^2 to your composer.json

We strongly advise against using version 1, which used OpenSSL's flawed random number generator as a last resort before throwing an Exception . Version 2 is safer: if random_compat would have previously fallen back to OpenSSL, instead you get an Exception that tells you, implicitly, "Fix your broken environment."

If you're developing an open source library, however, we recommend adding ^1|^2 to your composer.json instead of just ^2 to prevent version conflicts with dependencies that were released before random_compat version 2. This also allows users to opt into version 1 if they decide they really want to throw caution to the wind and trust openssl_random_pseudo_bytes() . (Part of software freedom includes the freedom to make insecure decisions.)

We don't have a definite EOL date in mind, but we will at minimum consider pull requests and new issues until PHP 5.6.x support is turned off for good.

CMS Airship (and Related Tools)

CMS Airship, which is currently beta software, is anticipated to see its first stable release before the end of July (assuming no setbacks). After that time, we will be supporting version 1 for three years (which is in line with PHP's release cycle).

A major version will be released every year, and will be pinned to the next non-patch version of PHP. So for example:

Airship 1.0.x -> PHP 7.0.0 and newer

Airship 2.0.x -> PHP 7.1.0 and newer

Airship 3.0.x -> PHP 7.2.0 (prospectively) and newer

Airship 4.0.x -> PHP 7.3.0 (prospectively) and newer

...

With the exception of version 1 (which is about six months behind PHP 7.0.0), all major versions will cease to be supported as soon as the respective PHP version has reached end-of-life. Companies that decide that they need long-term support may contact us about an exclusive, non-transferable Long-Term-Support contract for security patches for EOL versions of Airship. We have no plans for a generally-available LTS Airship in the near or distant future, as running out-of-date software is drastically contrary to the goal of keeping systems secure.

Minor versions will be released as-needed, but we're aiming for quarterly. Since CMS Airship will offer secure automatic updates, patch versions should be issued and deployed immediately (worst case: an hour, by default) to anyone who doesn't turn that feature off, thus keeping (hopefully-)everyone up-to-date and preventing vulnerabilities from becoming an avenue for mass-exploitation.

Long Term Support Considered Harmful

Some folks in the PHP community may be upset by our decision not to offer long-term-support versions of our software, or our decision to not support code intended to run on unsupported versions of PHP, or both. However, we feel that this is the responsible decision for our users and for the security of the Internet in general. We've long been proponents of keeping software up-to-date to improve your resilience against known security threats. Anthony Ferrara makes the case against supporting outdated PHP versions on his blog. Being complicit in other peoples' choice to run outdated versions of PHP is a contradictory stance for a security company to take.

Additionally, we have finite resources to invest in our projects, and we'd prefer to use them responsibly. Continuing to support old PHP versions for free means less time we can focus on creating new things or improving the state-of-the-art. Thank you for understanding.