Careful wording

Moonpig, an online greetings card company suffered a security vulnerability. While the vulnerability was serious, far worse was the company’s deliberately misleading statement in response to the disclosure:

Indeed this tiny subset of information was “safe”. What was leaked was all other personal information held by Moonpig about every customer. Much worse than a password or a credit card that can be easily changed. That the company issues a statement like this indicates how little they care about their customers.

And obviously the fact that the company knew about the problem for 17 months and did nothing.

Slate

Slate is a window management tool for OS X. It differs from most because it’s designed to offer customisation over sensible defaults. In short, to use a hackneyed phrase: a programmer’s window manager.

There are two ways to configure Slate: a declarative way and using Javascript. I use JS, and recently uploaded my configuration to Github. I think Slate’s an awesome tool, so I wanted to go through how I use it.

As a warning, if they spoke Javascript in a foreign country, I’d just about be able to order a beer there.

Firstly, I set up five hotkeys, bound in a chaining fashion. The first key combination in the chain is ctrl-space, followed by one of:

  • 1 to fill the left half of the screen with the current window.
  • 2 to fill the right half of the screen with the current window.
  • 3 to fill the screen with the current window.
  • 4 to size the current window to a specific size and location I happen to prefer for text editors.
  • 0 is a magic hotkey. When it’s pressed, I use a script to work out where to place my most commonly used applications.

Hotkeys 1 to 4 are fairly standard. To bind them is simple in Slate:

slate.bind("1:space,ctrl", function(){ 
    var current_window = slate.window();
    var current_screen_size = slate.screen().vrect(); 
    var w = current_screen_size.width; 
    var h = current_screen_size.height;
    position_window(current_window, 0, 22, w/2, h); 
});

The above, for 1 is hopefully straightforward. The position_window function is a short helper I defined.

However, the main reason I use Slate is for 0. I have three possible screen layouts: laptop + 27”, laptop + 24” and just the laptop. The way Slate uses Javascript allows me to move and size windows based on my current screen layout. In practice, this means whenever I connect or disconnect a screen, I hit Ctrl+space, 0 and have most applications moved to their preferred places.

First, I define window groups using several objects, each of which is added to a sizes array:

var normals = new Object(); 
normals.names = ['Firefox', 'Google Chrome'];
normals.position_27 = [0, 22, 1366, 1019]; 
normals.position_24 = [0, 22, 1366, 1019]; 
normals.position_11 = "full_screen"; 
sizes.push(normals);

Hopefully the attributes are straightforward:

  • normals is just a group. I could’ve used browsers in this case.
  • names is the application names to use this group for.
  • The three position_x variables define placements for the different monitor layouts above.

When I hit Ctrl+space, 0, a function is executed which loops over every application. For each application, I look in the sizes array for a group with a matching application name. If a match is found, the code pulls out the appropriate window metrics using the current main screen width and some constants for each of the possible monitors. Then it sets the size of the window:

var p;

if (screen_width === DELL_27) { 
    p = apps.position_27; 
} else if (screen_width === DELL_24) { 
    p = apps.position_24; 
} else if (screen_width === LAPTOP) { 
    p = apps.position_11; 
}

if (p === "full_screen") {
    full_screen(win); 
} else { 
    position_window(win, p[0], p[1], p[2], p[3]); 
}

The full code is here. There are a few special cases for troublesome applications, but otherwise this is it.

If you’ve wanted to control your windows in a comically precise manner, Slate is for you.

Docker's security woes

I’d love to use Docker and, particularly, Fig. The deployment of even this site would be much simpler if I could update individual containers rather than having a somewhat complex set of services running together on a single host.

As of now, however, I’m starting to lose trust in Docker’s security team.

In October, Docker, Inc. announced that version 1.3 of the docker tool would verify container images downloaded from the central docker image repository:

First up, in this release, the Docker Engine will now automatically verify the provenance and integrity of all Official Repos using digital signatures. Official Repos are Docker images curated and optimized by the Docker community to be the best building blocks for assembling distributed applications. A valid signature provides an added level of trust by indicating that the Official Repo image has not been tampered with.

Sounds great, even if it is a bit vague (“using digital signatures”? What strength? etc.). Well, two things:

  1. Why did it take until 1.3 to introduce this feature? I question Docker’s priorities.
  2. It doesn’t appear to work.

Following a trust, but verify approach, research in this post indicates that the code implementing the verification doesn’t appear to work correctly. The conclusion:

Docker’s report that a downloaded image is “verified” is based solely on the presence of a signed manifest, and Docker never verifies the image checksum from the manifest. An attacker could provide any image alongside a signed manifest.

The core problem is that even if you trust both the original provider and Docker’s stewardship of the image, you cannot guarantee the image isn’t modified by a malicious party before it arrives on your machine.

It’s worth reading the rest of the post to understand the scope of the exploits. In particular, they are mitigated if one can trust the images one uses. Red Hat discuss some ways to do this. This does mean that there appear to be safe ways to use the docker tool.

However, this still worries me. One of Docker’s core products is their repository of container images. This is the reason I questioned Docker’s priorities above: if one can’t verify the provanence of the image that ends up on your machine via that central repo (you can’t be sure it hasn’t been modified before arriving on your machine), this product isn’t workable for production systems. Particularly because docker’s recent serious security issues involved the processing of malicious images – see here and here – a level of trust in the images received from the repository docker provides is essential. I therefore find it problematic that image verification seemed low on Docker’s priority list.

In summary, if this issue is correct, Docker has trust issues to work out: this flaw should not have made it into a production release. As more features roll out, docker’s attack surface increases. I’d like to see work in progress to mitigate that. In particular, a reworking of the central deamon to run as few things as possible as root.

Updated: clarified my argument.

The small iPad

It sill amuses me, the way the iPhone feeds like this amazing tiny iPad when you switch to it after a few hours of reading on the iPad. And for a moment it feels like the iPad must’ve come first, because of that.

From AppEngine to Cloudant and Linode

The last rewrite of the code which runs this site was in 2009, when I changed from a static site generator I’d written in ruby to an AppEngine site I wrote when I was first learning python. In the main I was very happy with AppEngine: I’d not paid them a cent but they’d happily hosted my site for five years.

Lately, however, I’d begun to want a better understanding of the technologies the site runs on. AppEngine’s abstractions were becoming to much. I’ve wanted a server of my own for a while; I chose Linode (referral URL) because my friends using it haven’t had many bad words to say about it. I chose Cloudant because I work there and wanted to have an app I — sort of! — depend on running there.

While Linode and Cloudant are more abstract than running everything on a single physical server, they are at a lower-level. For Linode, I can make decent guesses as to the stack; it feels more graspable. Working at Cloudant, I’ve a decent understanding of the stack Cloudant use, and have contributed code across the service.

Overall the migration was very smooth, and proceeded in two stages:

  1. Continue running on AppEngine, but migrate the data layer to use Cloudant.
  2. Migrate the web app to run on Ubuntu on Linode.

Step 1 was the more complicated one, and I’ll probably write up something of the model and views I use for the site. For now, it suffices to say that, aside from when editing posts, every page on the site is driven by one or more Cloudant views rather than pulling the documents directly. While my data is miniscule — around two or three megabytes — the Couch model is a good fit, so I’m happy with that choice.

Step 2 was straightforward as the site didn’t use much AppEngine-specific functionality. It’s a cherrypy web app, using mako templates along with a few other libraries like markdown. The main change was choosing how to authenticate myself to the backend, as this was the main place I’d tied myself to Google’s infrastructure. For now, I’m just using HTTP basic-auth, with the site’s config file containing a username and hashed&salted password, and have removed multi-author support.

AppEngine also has an automated deployment tool, so there was also a bit of work in moving the source code to a private GitHub repository and setting up keys so the Linode server can check the code out. Once I’ve given the code a once over, I’ll probably make the repository public so the server doesn’t need any credentials for my GH account.

The actual sysadmin work on the Linode server was minimal, basic security steps followed by installing nginx and supervisord from the package manager. This stuff really isn’t hard if you’re just running a website or two, though I confess to relying on the assumption that the Ubuntu packages provide a secure installation.