So when the next openssl advisory comes out (like today), then instead of installing 1 patch, you have to patch and rebuild $(ls /usr/local/bin|wc -l) docker images?

Honestly, that's so much easier and faster than dealing with native dependencies sometimes.

Only if you build the docker images yourself... in which case you have all of the dependencies on your system. If you're not building them, then you are at the whim of every maintainer to rebuild with a fixed openssl.

Most of the time, that rebuild is as simple as "just push a new version"; if the base image is something like Ubuntu 16.04, it will get the update automatically with the next clean build. We already trust the maintainer to write good code that does what I expect; this is just one more thing.

But what you described is literally "the worst case scenario is as bad as before (building my own images), but it would commonly be better". I'll take that any day.

Also, a lot of apps don't need a full linux distro shipped with them. If your binary is statically linked (like, for example, anything written in Go), the docker image can start from scratch, resulting in an image only a few megabytes large and with no issues like you outline.

>But what you described is literally "the worst case scenario is as bad as before

No its not. Before you might just have to rebuild openssl yourself. Now you need to rebuild openssl for every docker image you use and rebuild every one of those docker images.

Guess how many docker images will make or accept TLS connections. That's how many you will need to maintain the infrastructure to build yourself to respond to openssl vulnerabilities if you run any kind of business that requires good security.

Vendoring (the go and container model of shipping software) is great when you work with perfect upstream devs. Otherwise it effectively means you have to build it yourself with patched dependencies for fixes and hope it works.

Wait until you run into a compat issue between the code and a patched dependency and the upstream dev says "won't fix" because you're not deploying the container provided and the security risk isn't addressed because it "doesn't seem that bad".

I agree that can be the case sometimes. I don't think it's the case when dealing with Homebrew.

Most images should not be affected by the advisory, especially something like openssl.

Still, it would be good to have something in between a packaging system and containers, so the whole repo of images could be quickly rebuilt on top of a new base image with an updated library (mixed-in image).

Since base images are shared, it would be the best of both worlds.

"wget" as one of the first examples shown and discussed here most certainly is affected by openssl, since it's used to access https urls!

yes, but only things that use openssl that you connect to untrusted input. (a substantial number, but far from all)

Generally though, this should only require patching images that provide openssl, which should be expected to stay up to date, not the utilities which use openssl. The utilities should be picking an openssl-providing parent image - assuming that's the case, you'd just rebuild. That would pull in the new openssl image, rebuild against that newer target, and that'd be the end.

Homebrew is using bintray for precompiled packages and I also don't have XCode installed (only the commandline tools). And I never had problems with Homebrew because of OS upgrade. This "issues" are all solved IMHO.

OS upgrades nearly always require re-installing more than half of my packages, which can only happen after fixing various command-line tools, which can only happen after updating xcode. And some things perpetually link to old versions, and the problems crop up over the next few weeks. And running a pre-release of OSX can cause looooots of complications. Generally though, for release-channel people, yes - homebrew has done a remarkably good job.

Obviously YMMV, but in a Dockerized world the required steps would be: 1) upgrade the OS, 2) maybe update Docker

And that's it.

Are you saying it is less likely for Docker for Mac to break when there is a new macOS?

Less likely, no. Easier to fix, yes. There is only one thing that can break: Docker. And Docker is developed by a company who's job it is to fix their software. With homebrew, we rely on each package maintainer to fix their software, and that fix to be pushed to homebrew.

Docker moves the problem from upgrading to a newer version of a library to updating to the bleedingest edge kernel.

What? I've never had to upgrade a kernel to use docker.

The only real dependency is OverlayFS, but that will stabilise eventually.