In a new post to his site Cees-Jan Kiewiet talking about "highest" and "lowest" versions of Composer-installed libraries and testing them in Travis-CI builds.

During DPC I've had a talk with Rafael about making sure you test all your possible versions, lowest, current, and highest. The talk was ignited by the infamous composer.lock file (whether to commit it or not).

He goes on to show how you can set up a multiple-version build with the help of the "dependencies" environment variable in your ".travis.yml" configuration file. These are then used in "before_script" commands that tell the Composer install which versions to load. He includes a screenshot of the resulting build and ends with a reminder from Jordi Boggiano (lead developer of Composer) about the resources a build like this takes up and not to do it very often.

In his latest post Pádraic Brady shares his thoughts about the state of TLS/SSL functionality in PHP and how he thinks developers should avoid the trap of "lowest common denominator" and opt for insecurity.

A few weeks back I wrote a piece about updating PHARs in-situ, what we’ve taken to calling “self-updating”. In that article, I touched on making Transport Layer Security (TLS, formerly SSL) enforcement one of the central objectives of a self-updating process. In several other discussions, I started using the phrase “Lowest Common Insecure Denominator” as a label for when a process, which should be subject to TLS verification, has that verification omitted or disabled to serve a category of user with poorly configured PHP installations.

This is not a novel or even TLS-only concept. All that the phrase means is that, to maximise users and minimise friction, programmers will be forever motivated to do away with security features that a significant minority cannot support by default.

He goes on to talk about how, in some places, targeting the lowest common denominator is okay, security isn't one of them. He also includes four basic concepts developers can adhere to to prevent this targeting:

• You should never knowingly distribute insecure code.
• You should accept responsibility for reported vulnerabilities.
• You should make every effort to fix vulnerabilities within a reasonable time.
• You should responsibly disclose vulnerabilities and fixes to the public.

He follows these up with three steps you can follow to migrate an insecure architecture into something much more robust. This includes identifying the consequences of the update and documenting the solutions you've chosen, be those configuration updates or library changes.

Recently the "prefer-lowest" option of Composer was mentioned in relation to testing for Symfony-based applications. In this new post to his site Matthieu Napoli shows how you can do it on any project that uses the Travis-CI continuous integration service.

Composer just got a new awesome addition thanks to Nicolas Grekas: prefer the lowest versions of your dependencies. [...] This amazing option will install the lowest versions possible for all your dependencies. What for? Tests of course!

He includes all the instructions you'll need to get your Travis build using this command line option, starting with testing it on your own system first. He shows a basic ".travis.yml" file with the configuration you'll need to provide it use the "prefer-lowest" (check out line 17). He does point out that you'll need to run a "composer self-update" first though, as Travis hasn't quite caught up with the latest Composer that includes this option.