On Airship

I’ve seen a lot of buzz about the Paragon Initiative’s new CMS, Airship. I can’t help thinking that really smart people are doing a lot of unnecessary work for a very small amount of gain.

Don’t get me wrong: I think a security-focused CMS is a Very Good Thing ™, but making a generic CMS is not only very difficult, but it’s also been done over and over and over (and over and over…) again. From the perspective of a Drupal developer, I’m left scratching my head over why they’d want to go down this road in the first place, but also at some of their arguments against Drupal specifically.

The latest article that I’ve seen (via /r/phpsec) is this one, which is supposed to be a laundry list of shortcomings in other CMSes. I was actually somewhat excited to read it, and had hoped that it would point out the rationale for building Airship in the first place, but that was sadly not the case, as there really wasn’t a strong enough argument to warrant building a brand new CMS.

Technical arguments

In no particular order, here are the reasons that have been presented for why Drupal is suboptimal and why I think those reasons aren’t a good reason for building a new CMS

Drupal does not offer automatic updates

I’d argue that automatic updates are fairly problematic. By definition, automatic updates require that the docroot is writable by the web process. We shouldn’t encourage that. That’s security 101. If someone does compromise your site, the damage that they can cause should be strictly limited to the site itself and not any of the files on disk (so basically just the contents of your database).

Note that Drupal did offer this functionality in 7.x, but it was removed because of the problems that it introduced.

In addition, large organizations that run Drupal do not want this functionality. Deployments have to go through a QA process at a minimum. Having the site suddenly change without a developer doing anything is something that’s really frowned on, especially when an update breaks something – and please, don’t tell me you’ll never ship an update that breaks things. It will happen sooner or later because people aren’t perfect, and because the possibility of a broken update happening exists, large orgs just disable that functionality altogether.

Small sites for local businesses and the like are arguably more sensitive to this problem. For a small business, having an unexpected technical expense when an update happens and breaks their site is a very big problem.

It seems entirely reasonable, though, that security patches get automatically applied by an out-of-band process (maybe some simple script that runs on a cron job). This gets tricky, but this problem is solvable in isolation, and if done correctly, could be useful to users of any CMS. That is, rather than fixing security for the 0.0000000000000001% of websites that use Airship, you could fix security for the > 45% that run Drupal, Joomla, or Wordpress.

It appears that the authors of Airship already opened an issue for this two years ago, but it hasn’t had much concrete work done on it: https://www.drupal.org/node/2367319

Drupal almost offers prepared statements

This is true. Drupal does do this out of the box (specifically, \PDO::ATTR_EMULATE_PREPARES is set to TRUE). However, if you look at the commit that created that particular line the code, you’ll see that it was originally written in 2008. PHP has evolved somewhat since then, of course, and it’s entirely possible that the reason for that configuration choice is no longer valid (specifically, it was because using actual prepared statements skipped the query cache, which would have killed performance – more on security vs. performance later).

There’s already an issue open for this. It just needs an hour or two of somebody’s time to get it to the finish line. From what I can see, there are no objections to committing it once it’s ready.

Drupal doesn’t use password_(hash|verify)()

Also true. It’s mainly because nobody has pushed this issue forward since June 2015. Historically, PHP obviously didn’t have password_hash() or password_verify(). It’s not so much a conscious choice not to use those functions, but more of a historical byproduct.

Again, the issue that could fix this is already open and in progress. It just needs some help getting over the finish line.


There’s a comparison on the Paragon Initiative website that lists other “missing” features in the major CMSes, but I’d argue that some of these are a little contrived. Even if you must have those features in a CMS, Airship could be a Drupal distribution just as easily, and reduce the maintenance burden that comes with building and maintaining an open source CMS.

In addition to the three arguments from above, these are the remaining ones that I can see:

  • Content Security Policy/HTTP Public-Key-Pinning: I’m not sure that there’s really a use-case for managing these headers through the UI. It seems like this is a set-it-and-forget-it kind of thing that you’d do while configuring the vhost for your site, for instance. If you really want a UI to manage this, there’s always the seckit module, though public key pinning support is still in progress.
  • TFA: Not every site needs nor wants this, and even if it were included by default, everyone has different ideas about how this should work. Not everyone wants to use OATH, for instance. I work at a company where they would almost certainly want to use the RSA token system. Others might want to send an SMS message. Certainly doable in a Drupal distro though, and there’s already a contrib module that handles it.
  • Secure “Remember Me” checkboxes: If the default Drupal implementation of this checkbox is not secure, I’m 100% certain that a patch would be gladly accepted to fix it.
  • Login Brute-Force Resistance: Since you have a question mark in your comparison for Drupal, I’m happy to inform you that Drupal does support this via the Flood component in Drupal core. You can see the implementation here.
  • Account recovery: Opt out: The vast majority of users will never want to opt out of the ability to recover their account. In fact, I couldn’t even find a contrib module that handles this. If you really want it, though, it would be pretty simple to write a module that does it and include it in a distro.
  • Account recovery: GnuPG encryption: Oh, c’mon. This is clearly a case of being stuck in a security echo chamber. Yes, this is inarguably a good feature for the people that have GPG keys and know how to use them. However, the number of people that applies to is ridiculously small. Again, you could write a module to handle this pretty easily, but I seriously doubt that this should be a negative point against Drupal (or any other CMS) for all but the most ridiculously paranoid of sites.
  • Minimum PHP version: Drupal’s minimum version is 5.5.9 for Drupal 8.2.x. That doesn’t mean that we’re encouraging people to run that specific version of PHP. It means that Drupal is capable of running on that version of PHP. We utilize newer features if they’re available (via the Airship author’s random_compat library, for instance).
  • Code footprint: Yes, Drupal is quite large. It also does a lot of things. What you’ve completely glossed over in your comparison table is all of the other features of Drupal. For instance, being able to create and manage data fields through the UI, then create rich interfaces for viewing that content. You can model almost any kind of data in Drupal just through the UI. I don’t know if Airship allows for that, but my point is, you’ve ignored that, and then argued that Airship is just the right size. My suspicion is that the bulk of Airship’s code is specifically for handling the exact features on this comparison table and not much more than that.

Business arguments

All of the above aside, I cannot, in good faith, recommend Airship to my clients. This is for a number of reasons, not the least of which is that the public release is only five months old. It’s also essentially untested and unvetted in the wild, and the majority of the selling points that Airship advertises are only interesting for security-minded people like the authors of Airship.

That is, I’m not going to be able to sell my clients on a brand new CMS just because it supports gnupg encryption of recovery emails. They don’t care about that. What they care about is being able to get their content online quickly, have a nice way to manage that content, and when they need to expand the functionality of their site, they want to do it quickly and without a lot of headache.

On those fronts, Airship doesn’t do well as far as I’m concerned. Were it not for Drupal’s ecosystem of contributed modules, there’s no way that the projects I’ve worked on would have gotten done as quickly as they did.

My suggestion

I’ve seen a lot of naysayers on Reddit and such talking trash about Airship, and maybe I’m grouped into that statement as well because of this blog post. However, I don’t think I’ve seen anyone really opposed to the idea of a security-focused CMS. People are more often opposed to the idea that it needs to be a completely separate product. Doing some of these things in Drupal core is likely going to be a tough sell. However, the good news is that almost everything in Drupal 8 is swappable via the dependency injection container. You can literally tear out the password handling, for instance, and replace it with your own.

In short, I’d recommend the following:

  • Start a distribution project on Drupal.org called Airship.
  • Add some of the existing contributed modules to your distribution that handle your use cases
  • Write an import script using the Migrate module (which is in core) to pull in content from installations of Airship 1.*.
  • Write a theme that makes the Drupal UI look exactly like Airship does now. This seems like it would be a massive undertaking, but it’s really, really not.
  • Maybe write a small helper module that provides the specific menu links that you want displayed in the admin UI.
  • For the use cases that aren’t supported by existing contrib modules, just write the modules. I think I only came up with two specific cases that weren’t covered (which were the account recovery features).

It may seem like a fair amount of work to do this, but I see some pretty large benefits coming out of this:

  • (Biggest reason) You don’t have to maintain the entire CMS and all of the infrastructure and support headaches that come with it. You can focus on building the parts that you care about, and when a new version of Drupal comes out, you get the bug fixes and new features essentially for free.
  • You get all of the power of Drupal, and all of the security features that you want as well.
  • You can have a security-focused testing ground, and if the security enhancements that you’re proposing work well, there’s a good chance that they could get pulled into Drupal core.

Airship authors: if you decide you want to give this method a try and you get stuck at any point, I’m more than happy to assist where I can. Reach out via my contact page or send a note through Drupal.org.


comments powered by Disqus