Hacker News Reader

Comment by onli | Hacker News Reader

I kinda doubt that. You would need to update the components inside the docker container, right? If you simply activate the container after years of inactivity you will have a complete insecure setup, as there would be no security updates applied. That's not even acceptable for side projects.

View on HN

Dunno why you got downvoted, you are exactly correct.

Another thing that rots when it's "years" is the trusted CA bundle, so you cannot even talk to remote peers until you update it.

The usual trick is to mount /etc/ssl/certs from the host.

This also means stuff like "extra" CAs can be configured at host level.

The packaging issues... 99% of all CVEs are junk, in context - not reachable except in exotic configurations, component not used in container, kernel bugs reported against kernel headers package in the container because of course no docker scanner filters those out, cve is actually misreported, tons of "locally" (aka not) exploitable issues esp privesc... but yeah, ok, it's the 1/100 that gets you.

I know for solo-founder discussions about cut-throat effort expenditure judgements in the here and now don't really need to consider their project being shuttered and later revived, but the first step of reviving old projects is never "put it on a public server" or "update all the packages to ensure the security patches are up to date", it's always just getting it running again. I've been in scenarios where that effort alone was significant.

Good luck updating old and hand-configured VM. Most of the time running Docker image is just invoking one app without entire system services (except host system), then securing is often just bumping base image version to some recent one.

You don't hand configure VMs, just like you don't hand configure containers.

You use packer and vagrant for that, and you bump base image versions, just like in Dockerfiles.

Reply on news.ycombinator.com