hroot

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-initia...

I've been doing a lot of research lately into more deterministic dependency management and reproducible builds by leveraging hashes via git. You might be interested in MDM[1], which is a general-purpose dependency manager for binary blobs. Specifically for container images, you also might be interested in hroot[2] -- it separates the concept of the image and transport out from the containerization system. I agree wholeheartedly that it's the image permanence that's the interesting part about containers right now. In the last 24 hours I actually had an experience where a docker setup full of apt-get's failed to reproduce an image (new deps were added upstream that broke the system). Fortunately with hroot, I had the exact filesystems I had previously produced in a permanent, transportable system, and all covered by a hash so my productio