Re: [Tei-council] meetings and containers (was "Re: Stylesheets (and other) meeting time")

Apart from rare exceptions, all you should need to do to get patched versions of packaged software is to build a new image. There is actually nothing I can do on my end to facilitate this process—other than possibly change the base system I’m using. I maintain the Dockerfile that Docker uses to build the image that you run in a container. My understanding of the process is that updates are applied when the image is built. If you want to keep a container hanging around, you could also periodically run apt-get update && apt-get dist-upgrade in your container. The attack vectors against your personal machine are not going to be multiplied by doing TEI things in a container that isn’t listening on any ports. You’re probably a bit safer if anything, even running an unpatched system. If a hacker could get access to it, they’re already in your machine, or they’ve compromised something the TEI build process needs. In other words, you were already doomed. Note that the above does not apply if you’re running a server—paranoia is fully justified in that case. Hugh

On Jan 2, 2020, at 14:10, Bauman, Syd wrote:

Whether I make it or not, I hope the topic of keeping the Docker containers updated is discussed. My thoughts on this topic follow, in no particular order.

* It is definitely important to keep the OS running in a Docker container up to date with security patches. It may not be as big a problem as Martin worries it is, especially if we are all vigilant in leaving a container running for the minimum amount of time necessary. But it is still important enough that we should have a process for doing it.

* The solution is probably administrative, not technical.

* It is probably unfair to insist that Peter and Hugh be solely responsible for doing this. (That said, if they don't object, I don't either. I would if it were only 1 person -- at least 2 people should know how to do everything that is even semi-important.) Could be a rotating responsibility.

* My suggested administrative idea: Once a month, 1-24 hours *before* the Council meeting, the Docker maintainer or designee should update each container with the latest OS security patches. (Chair should send a reminder 48 hours before the meeting.) Immediately *after* the Council meeting each Council member should download and install the updated container.

* Peter pointed out that doing such an update might break the build within the container. He's right, but that's no reason not to install security patches. It's a reason to fix the build process so it works on a properly updated system. Doing this on meeting day, I figure, gives us a higher chance of noticing a build fail, finding a fix, and promulgating the solution rapidly.