On Sat, Nov 12, 2016 at 09:18:26PM +0100, Nicolas George wrote: > If I understand correctly how Docker works, its images are big blobs > that contain the program they are meant to distribute plus all its > dependencies. Am I mistaken? That's broadly true, at least, they are presented to the user that way. > If it works like that, that means when the next OpenSSL security issue > is found, we have to cross our fingers very tightly and hope whoever > released the image will release an update with a fixed library. If the dockerized application you were using did not use OpenSSL, you don't need to do anything. If it does, then it needs to be rebuilt. As a user, you could wait for the image author to rebuild it, then pull the newer version. It's quite likely the image author based their image on top of another, and that the parent image (or a parent image somewhere up the chain) is the "owner" of the problem. For example, if the image you were using had been built on top of the "debian" image, the image author would have to wait until the author/owner of the "debian" image updated, first. (Note: that isn't the Debian project, confusingly!) This is pretty bad. Another option is, you create a new derivative image yourself, which is built on top of the application image you were using, and updates OpenSSL. That would be roughly as simple as a Dockerfile with two instructions FROM some-application-image RUN apt-get update && apt-get upgrade -y (the above fed to "docker build -t my-new-image-name <location to Dockerfile>") The abstraction is already a bit broken though, because you need to know that the image was based on a Debian-like OS; that OS needs to have updated the OpenSSL library; the application has to continue to function with the new library version (and that might not be tested yet) And none of the above is automatic. -- Jonathan Dowland Please do not CC me, I am subscribed to the list.
Attachment:
signature.asc
Description: Digital signature