Announcing Ensemble

Posted by Simon Hamp - 11th June 2018


Bringing your Composer dependencies together


TL;DR: Ensemble is an app to help you stay on top of your Composer dependencies by monitoring your applications and packages for outdated dependencies and checking for known security vulnerabilities. It’s currently free while in beta. Please sign up and try it out, I’d love your feedback.


Composer has been a fantastic boon to the PHP community. Building on concepts of the past and embracing the technology of today to build a practical and pragmatic solution to package management, Jordi Boggiano et al have changed the face of PHP and literally handed the renaissance over to the rest of us.


As the community has roundly embraced Composer, it has rapidly matured and stabilised. And the sheer volume and quality of packages available shows just how powerful and useful open source can be, even despite the many duplicates and seemingly pointless packages in existence (that’s a problem for another day).


In my opinion, Composer is one of the best package managers around and Packagist is probably the best thing to have happened to every PHP developer who’s not stuck on PHP <5.2.


I’ve personally had very few problems with Composer: it’s configuration and handling of package versions is extremely flexible and the fact that it’s available for free and is mostly open source itself is a triumph.


But there is still one area of package management in PHP that we don’t seem to have covered well just yet.


Keeping you informed about outdated packages

One of the things that it lacks – largely as a consequence of its design – is any kind of out-of-the-box automation around informing the developer about out of date packages.


I’m not sure if this is on the roadmap anywhere for Composer. In practice, it’s actually quite tricky and there are a lot of nuances that make that sort of complexity more suited to a separate piece of tooling.


Some solutions have been raised up:


  • The composer outdated command. Run it manually to see quickly which packages can bee updated, then run composer update to get the ones that can. It doesn’t provide loads of detail, but it’s quick and functional.
  • The sllh/composer-versions-check package. Install it globally, get outdated package data (with a little extra detail) every time you run composer update.


I want these tools to do more though.


My main gripe is that they both require my input — I have to consciously and synchronously think about them, so there’s no real automation involved.


So for apps that I hardly touch any more — that’s probably running on a bunch of outdated packages running less efficiently than it might otherwise be able to — I might never know just how bad the situation might be.


Security Vulnerabilities

The worst possible consequence of this is that some production app that’s not been worked on in a while is relying on some packages that have exposed a potentially fatal security flaw.


The flaw may have been reported, addressed and a fixed version of the relevant package released. But how would you know?


Unless you’re vigilant and watching CVE reports from the right places like a hawk, you might never know! And you’re far less likely to randomly run updates for an app you’re hardly working on (unless you also have a repeating calendar event for that).


I know it’s an extreme, worst-case scenario, but as more and more packages are released and more and more apps are built using those packages, it’s a scenario that is becoming increasingly likely. There have already been a number of serious vulnerabilities for well-known packages and other package managers such as NPM are already seeing high-profile package vulnerabilities.


Even if you’re vigilant with dependency updates, there’s always a window of opportunity that exists between when a vulnerability is found and when you become aware of it.


This is a complex problem, and for sure no one party is solely responsible:


  • As a good package creator/maintainer (and decent human bean), you should be alert to flaws and vulnerabilities (in your packages and your dependencies), patching your own code/reporting issues to other maintainers and communicating potential issues to your dependents somehow.
  • As an app developer, you should to be on top of your dependencies (and their dependencies), reviewing security lists, reporting flaws to maintainers, updating your packages and your application.
  • As the primary delivery mechanisms, Composer and Packagist should probably do more to highlight packages and versions with vulnerabilities.


Basically, this takes a lot of time on the part of every one involved. There are growing attempts to tackle this, such as SensioLab’s Security Advisories Checker & Database and the roave/security-advisories package.


If you’re already making use of these tools, give yourself a pat on the back. If not, please check them out!


These approaches are still quite manual, though, and I want something more automated. I want to set it and forget it!


Bringing it all together

Ensemble is the French word for ‘together’. In music, it represents a group of musicians (instrumentalists and/or vocalists) that have different skills coming together to create complimentary sounds in favour of specific genres.


That’s why I picked Ensemble as the name of the app that will bring all of your Composer package information into one place. It's a tool that can keep you alerted automatically about updates, security issues, licences and more for every single one of your own apps and packages.


How it works

After registering an account and adding your first app, you will need to install the plugin. It’s Laravel-only at the moment, but if you can you help extend it to other platforms, I’d love to chat. Please message me on Larachat or LaravelUK Slack groups (I’m @simonhamp on both)!


After configuring the plugin and Ensemble, it will be able to fetch the latest details about all of the packages your app uses and start alerting you automatically via email.


  • No manual uploading of your composer.json or composer.lock file
  • No special commands to run
  • No waiting until the next time you have to composer require some new package


Requirements

  • Your app needs to be accessible via the internet
  • the route that the plugin sets up needs to be available publicly, and
  • Composer needs to be installed on the server that your app is running on.


Once Ensemble has started syncing with your app, you’ll be able to see package information appearing in the Dashboard:



A note on security

I take security very seriously. It’s critical that your dependencies don’t become your app’s Achilles heel.


I also dislike connecting thrid-party apps directly to my repos. In some cases, it’s just not even possible — what if that project isn’t under version control? Or what if your corporate security policies don’t let you connect apps to your repos?


An open source package that you can install yourself and verify internally is far more secure than some hosted app that you have no insight into. And with the potential fluid ownership of VCS hosting solutions, and their evolving policies and controls for third-party apps, you’ll want more security than giving some third-party app the ability to clone your super-secret-codebase into a Docker container on some server farm in an unknown territory.


That’s why when we’re bundling up the list of packages your app uses, we take care to make sure it’s strongly encrypted using a unique key that only you and Ensemble knows. Please don’t share your key with any other apps.


This also means that even if your app still runs over HTTP, it’s going to be really hard for someone to find out what packages your app is using.


In case your key is compromised, you can easily generate a new one in your Ensemble dashboard.


It’s not just apps, you know…

I’ve got a lot of ideas buzzing around my head for Ensemble, but one of the main ones is to make it available to open source packages too.


This would need to work slightly differently to how it works for apps, but principally it offers all of the same benefits… so whether you’re building an app or a package that has Composer dependencies, Ensemble will be able to work for you.


Automated alerting

The main goal with Ensemble is to save developer time — by reducing the number of things we need to think about, we reduce risk, giving ourselves time and space to think more clearly and focus on what matters the most.


At the moment, this is done by simply sending you a daily email letting you know which of your apps are outdated and which ones are fully up to date, giving you a snapshot overview of the state of your dependencies.


In time, this will be more configurable and more reactive, with the possibility of immediate alerts, especially for vulnerabilities.


This is just the beginning and I’m excited to see where this can go.


If you’re:


  • a PHP developer using Composer, or
  • a Product Manager running apps built on PHP that rely on Composer packages, or
  • a Composer package developer,


Please give Ensemble a try today!

Log in or sign up to leave a comment.

Sign In With