Red Hat Security Blog

The most important information is missing - did the attackers get the package signing key? The comment "the window for package compromise was very very small" is a bit ambiguous.

That the security of package integrity is so fragile should greatly concern all of us. Almost all big Linux distributions rely on downloading compiled packages signed by a single key. If the build system is compromised your Linux distribution of choice will happily give you trojaned packages that you install as root. If the signing key is compromised a man-in-the-middle is required, but the difficulty to mount an attack is decreased due to the fact that most repositories don't transport over TLS.

The situation can be improved in many ways. By making the build process deterministic many parties can compile the same package and compare the result, alerting the community if one of the build systems report a different checksum. Package managers like apt and yum should be extended with the ability to rely on signatures from multiple parties.

The Tor Project, Debian and Fedora has started working on the first problem, but I don't know of any efforts to support multi-sig.

https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise

https://blog.torproject.org/blog/deterministic-builds-part-two-technical-details

https://wiki.debian.org/ReproducibleBuilds

https://securityblog.redhat.com/2013/09/18/reproducible-builds-for-fedora/

I agree that security should have been in place before they went 1.0. However, if you look at the work on the version of the registry (docker/distribution on github), they are taking things more seriously and trying to get the basics right.

I find your last point a bit strange. We all know the Docker development experience is a lot better than raw lxc. I'm saying you can (and probably should) be more careful about provenance than the Docker Hub is. Note that there are alternatives to the Hub with better provenance stories e.g: https://access.redhat.com/search/#/container-images (from https://securityblog.redhat.com/2014/12/18/before-you-initiate-a-docker-pull/) This might make things a bit more awkward than it was before, but it's still not the same as raw LXC.

I feel your anger and I think it's understandable, but that doesn't mean things won't get better.

According to Red Hat, the current best way to secure your Docker usage is to `127.0.0.1 index.docker.io` and use an alternate transport.

The core "translate flags into running container options" works fine IMO, it's the centralized transport causing the issue.
Which isn't the end of the world, as distributing tarballs is not exactly a demanding task.

As an example / plug, I helped write a (prototype) tool that lets you import a docker image from the registry, then transport / version it separately:
https://github.com/polydawn/hroot

Thus, integrating via `docker load` + `docker export` is possible & reasonable.

Linked from the article:
https://securityblog.redhat.com/2014/12/18/before-you-initiate-a-docker-pull

As I understand this, any CGI script could be affected. Even if written in a different language if it turn does an os.system (or equivalent). More info here:
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
The permissions would only be as the web server user, but that allows all sorts of things to be run that are quite dangerous (resource exhaustion, attacking remote machines, downloading code and running it)