Docker 1.3 is out

For those wanting to avoid upgrading to a new boot2docker release you can patch the vulnerability with the following command from the boot2docker shell:

  sudo sed -i "s/DOCKER_TLS:=''/DOCKER_TLS:=auto/g" /etc/init.d/docker && sudo /etc/init.d/docker restart

Most of the time these processes only need the network to communicate with each other. When there is a legitimate reason for processes to share the same filesystem, process namespace or network address (for example for debugging), that's when `docker exec` becomes helpful.

If you want to start multiple separate processes, then you'll need to use some sort of init system. This is not really any different than Linux itself.

https://github.com/docker/docker/blob/master/trust/trusts.go...

Ideally docker users could sign their own images and provide their own keys to do signature validations. What is the timeline on this work? With out this, "digitally signed images" means "locked into Docker, Inc- otherwise no security", and is very misleading.

A very basic implementation would be to read certs out of a directory on the filesystem and is how all other package managers handle this.

Edit: I missed the part in the post that even if the signature fails, the container still runs. The signatures do nothing. Got it. Preview.

I can already see that `docker exec` and `docker create` will allow me to get rid of a number of admin and configurator containers.

When I started playing around with boot2docker, I was gagging for the ability to share directories with OS X. However, it turns out that I didn't really need that once I realised that caching means that building images is very fast.

I'd hesitate before calling it a "security problem" with Docker. It's a highly-requested security feature. The absence of it makes containers less secure, but does not make them vulnerable. There are use-cases for Docker without user namespaces, but user namespaces will make Docker better and will make containers more secure.

We do distinguish between the security of the Docker engine and the pieces of our ecosystem and the security of containers themselves. We seek to improve both.

Vulnerabilities such as the one fixed today in boot2docker 1.3 whereby either web browsers or containers may control the Docker daemon and perform remote code execution are serious issues in Docker itself and/or its ecosystem of products. Resolving such vulnerabilities is not, for me, less important than adding user namespaces.

Our other sites, including the Docker website and the Docker Hub already have relatively aggressive cipher suites and have disabled SSLv3, protecting it from POODLE.

Is this really cheaper and more effective than cleaning up your code base so that it doesn't require complete ownership of the host environment in order to run?