4 ms·

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 y

by onli 5y ago

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.

outsomnia 5y ago
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.
- xyzzy123 5y ago
  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.
evilduck 5y ago
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.
imhoguy 5y ago
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.
- purerandomness 5y ago
  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.

by onli 5y ago

outsomnia 5y ago

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.

xyzzy123 5y ago
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.

evilduck 5y ago

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.

imhoguy 5y ago

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.

purerandomness 5y ago
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.