In addition to the "minimalist" aspect, this image seems to offer better practices on a security level than official Debian images. From their README: "The images are built daily and have the security release enabled, so will contain any security updates released more than 24 hours ago."
> In addition to the "minimalist" aspect, this image seems to offer better practices on a security level than official Debian images
I'm skeptical about this claim. Almost every image built from the Debian official image begins with `apt-get update` before you can actually install anything, which means you will almost always have the latest packages at the time of building.
While not as small it is trivial to make an up-to-date debian base image (or Fedora/Arch) any time you want. If you care about security you probably don't want to use random unverified images anyway.
$ sudo debootstrap stretch mydebian http://mirrors.kernel.org/debian/
$ cd mydebian
$ sudo tar -c . | docker import - mydebian
Plus you can add files to the system before taring etc...
If you have significant work to do on an image a Dockerfile can often be far more complex than this method.
No offence intended and these terms are not tightly defined but I would call your imaged a 'baked' image.
My feeling is that I don't know how long a base-image will stick around. If ca-certificates is installed in my base image it may end up trusting revoked certificates.
IMHO it is better to know you need to install/bake in ca-certs from a trusted source than to having a built in, potentially compromised CA cert installed.
Baked images, which I use to reduce instantiation time, or 'golden' images that are immutable infrastructure tend to have shorter lifespans and the CA package is carried in the application dependencies and more likely to be up to date.
It is not intended that users will download this baseimage (although it is a supported configuration, you can use FROM phusion/baseimage) but, that this will be an image definition that users can easily rebuild and build off of it.
Step one in Docker competency is "do you know exactly where your image comes from, and can you rebuild it from scratch without trusting that some rando on the internet didn't put bad stuff in there?"
Step two is "ok, do you really actually build them, though"
This image has traditionally been based on LTS ubuntu, and if you look at the CentOS derived version that hasn't been updated since 2014 (pokle/centos-baseimage), they chose not to include ca-certificates or hardly anything else.
(I'm assuming that tianon/centos:6.5 does not install ca-certificates by default...)
I'm sure many people use FROM phusion/baseimage but personally, even as a maintainer, I don't. I'd change the image source to whatever upstream of Ubuntu I'm preferring today, and probably build that from scratch too. The value in this image is not that it comes pre-built, it's that the build is tested and supported. /side tangent
You can go ahead and explain what you think base image means then, because it's not obvious to me how this is different than that (and I'm a domain expert.)
A base image is an image that you're meant to build off of, it is not meant to be deployed as an application but as a base for your image. What part of what I said was disingenuous? I gave a link to some source code that I didn't write and provided a counter example, identifying myself as a contributor. What did you contribute?
Great misunderstanding of what I said, this is two in a row when considering the above, bravo.
What is wrong with your first comment is:
1. zenlikethat's comment obviously talks about base images in general, not about a specific base image ("...most base images...")
2. Your reply which disagrees with that is based on a very basic fallacy (there is a one base image which contains ssl so zenlikethat's claim is false!?)
3. Your example is a base image which you're a maintainer of
Considering (1) is obvious and (2) is a very basic fallacy nobody here should fall for, your comment seems like an intentional and unwarranted plug for "phusion/baseimage" instead of a valid and honest disagreement to zenlikethat's comment. (extra points for unwarranted plug of your domain expertise in immediate parent comment)
I'm supposed to provide examples that I am unfamiliar with?
Forgive me for misunderstanding your comment, but `"base image" != "baseimage"` did not have a great deal of substance to it, nor did it provide me with any insight about the topic.
I provided an example, to facilitate the discussion. So back to my last question, what did you contribute?
I couldn't find anything in the post that correlates the Debian updates with security notices (which is your main point). If a security advisory comes out every 2-5 weeks and Debian updates on the same schedule, then I don't see a problem. But the data is just not there.
(These have to be advisories actually affecting the image, not all of them)
A recent analysis showed that the debian:latest image is "updated roughly every month" https://anchore.com/blog/look-often-docker-images-updated/