[mschuster91]

Stuff like this is why I base my docker images off Ubuntu or Debian and regularly rebuild them. This way I always get the security updates from Debian/Ubuntu.

The problem with all images which base on something that is not an official distro image is that these packages always have to depend on the base image author to regularly update the images. There is no such thing as apt-get upgrade in a docker only environment, and I'm not really looking forward to the next Apache RCE vuln or the next Openssl desaster. People with long-running containers will be hit hard.

[Gigablah]

I don't understand your conclusion. The exploit in the article was reported to the Alpine Linux maintainers and the fix was promptly made to apk-tools (https://git.alpinelinux.org/cgit/aports/commit/?id=b849b481a...), so if you rebuilt a docker image based off Alpine you'd have gotten the security update like you described.

[mschuster91]

> so if you rebuilt a docker image based off Alpine you'd have gotten the security update like you described.

Only if I directly base off my image from Alpine. All images that base off something that either directly bases off Alpine (or worse, with more intermediaries) have a problem as ALL images in the chain must be rebuilt.

That is the core problem.

[Gigablah]

TBH you'd have the same problem if you based your image off an intermediate Debian/Ubuntu-based image.

I always build my images directly off Alpine anyway, or a base image that I control.

(In this case though, the security fix is for the apk-tools package and not the distro itself, so as long as you have apk update+upgrade in your final build, whether the intermediate images are rebuilt doesn't matter.)

[subway]

Your best bet is really to build your base image using debootstrap or similar. The 'official' images are often a joke. For the longest time, the maintainer of the 'official' Ubuntu image had no clear association with either Docker Inc or Canonical.

edit: To clarify, the images themselves are quality, and do get generated from Canonical's rootfs tarball, but the trust path for a huge chunk of binary data now hinges on a single individual, rather than a corporate entity.

[tfvghbv]

> the trust path for a huge chunk of binary data now hinges on a single individual, rather than a corporate entity.

You make it sound like it was a bad thing. It's not.

[atonse]

It is definitely a bad thing from a risk standpoint, no two ways about it. Simply because that person could get hit by a bus, burn out, etc.

[k_sh]

I'd trust Canonical for Ubuntu images over a random internet citizen that decided to provide them.

[s_kilk]

When it comes to base images, I'd much rather trust Canonical, Docker Inc, Redhat, etc than Some Dude.

[cupcakestand]

> Stuff like this is why I base my docker images off Ubuntu or Debian and regularly rebuild them.

How can a server running Docker rebuild itself a new image and deploy it? Without your intervention. With cron?

[mschuster91]

I do it the "old fashioned" way. Manually build the images on the laptop, increment the version prior to pushing it to Nexus, and then increment the version in DC/OS.

Reminds me, I actually could automate this using Jenkins, it has an interface to Marathon (which backs DC/OS)...

[cupcakestand]

If you want to automate it just use unattended upgrades for security updates within the container.

[mschuster91]

This works for sure but is ephemeral - when you have to restart the container for unrelated reasons, the upgrades are lost.