search

mailcow / mailcow-dockerized

mailcow: dockerized - 🐮 + 🐋 = 💕
https://mailcow.email
GNU General Public License v3.0
8.33k stars 1.13k forks source link

outdated docker hub images #2690

Closed christianbur closed 5 years ago

christianbur commented 5 years ago

Describe the bug, try to make it reproducible When I use the mailcow images from the Dockerhub, they use an outdated base image. Here is a current example:

'mailcowdockerized_unbound-mailcow_1' base image out of date (current version 3.9.4) Alpine Version: 3.9.0 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_netfilter-mailcow_1' base image out of date (current version 3.9.4) Alpine Version: 3.9.0 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_acme-mailcow_1' base image out of date (current version 3.9.4) Alpine Version: 3.9.0 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_solr-mailcow_1' base image out of date (current version 3.9.4) Alpine Version: 3.9.2 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_watchdog-mailcow_1' base image out of date (current version 3.9.4) Alpine Version: 3.9.0 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_dockerapi-mailcow_1' base image out of date (current version 3.9.4) Alpine Version: 3.9.0 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_rspamd-mailcow_1' base image out of date (current version 18.04.2 LTS) Debian Version: buster/sid PRETTY_NAME="Ubuntu 18.04.1 LTS"

'mailcowdockerized_postfix-mailcow_1' base image out of date (current version 18.04.2 LTS) Debian Version: buster/sid PRETTY_NAME="Ubuntu 18.04.1 LTS"

'mailcowdockerized_sogo-mailcow_1' base image out of date (current version 9.9) Debian Version: 9.6 PRETTY_NAME="Debian GNU/Linux 9 (stretch)"

'mailcowdockerized_clamd-mailcow_1' base image out of date (current version 9.9) Debian Version: 9.6 PRETTY_NAME="Debian GNU/Linux 9 (stretch)"

'mailcowdockerized_dovecot-mailcow_1' base image out of date (current version 9.9) Debian Version: 9.6 PRETTY_NAME="Debian GNU/Linux 9 (stretch)"

#####################################################################

'mailcowdockerized_php-fpm-mailcow_1' base image up to date (-> php:7.3-fpm-alpine3.9) Alpine Version: 3.9.4 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_nginx-mailcow_1' base image up to date (-> nginx:mainline-alpine) Alpine Version: 3.9.4 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_ipv6nat-mailcow_1' base image up to date (-> robbertkl/ipv6nat) Alpine Version: 3.9.4 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_memcached-mailcow_1' base image up to date (-> memcached:alpine) Alpine Version: 3.9.4 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_redis-mailcow_1' base image up to date (-> redis:5-alpine) Alpine Version: 3.9.4 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_mysql-mailcow_1' base image up to date (-> mariadb:10.2) Debian Version: buster/sid PRETTY_NAME="Ubuntu 18.04.2 LTS"

the version was determined with the following commands

docker exec -it mailcowdockerized_X-mailcow_1 sh -c "cat /etc/debian_version"
docker exec -it mailcowdockerized_X-mailcow_1 sh -c "cat /etc/alpine-release"
docker exec -it mailcowdockerized_X-mailcow_1 sh -c "cat /etc/os-release | grep PRETTY_NAME"

Resulat: all base images of mailcow have not been updated for some time and do not correspond to the current security level.

if you follow the documentation I always get the outdated Docker Hub versions, I can build the images myself with "docker-compose build", but then I can't use the ./update.sh anymore because the "new" images are overwritten by the old docker hub imges again and again.

Wouldn't an automated creation of images make sense (however, i have no experience with it)? https://docs.docker.com/docker-hub/builds/

raoulbhatia commented 5 years ago

+1 for automated builds!

andryyy commented 5 years ago

This is a duplicate with other issues explaining why it is not necessary. For some containers it would make even zero sense.

Am 07.06.2019 um 00:29 schrieb Christian Burmeister notifications@github.com:

Describe the bug, try to make it reproducible When I use the mailcow images from the Dockerhub, they use an outdated base image. Here is a current example:

'mailcowdockerized_unbound-mailcow_1' base images out of date (current version 3.9.4) Alpine Version: 3.9.0 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_netfilter-mailcow_1' base images out of date (current version 3.9.4) Alpine Version: 3.9.0 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_acme-mailcow_1' base images out of date (current version 3.9.4) Alpine Version: 3.9.0 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_solr-mailcow_1' base images out of date (current version 3.9.4) Alpine Version: 3.9.2 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_watchdog-mailcow_1' base images out of date (current version 3.9.4) Alpine Version: 3.9.0 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_dockerapi-mailcow_1' base images out of date (current version 3.9.4) Alpine Version: 3.9.0 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_rspamd-mailcow_1' base images out of date (current version 18.04.2 LTS) Debian Version: buster/sid PRETTY_NAME="Ubuntu 18.04.1 LTS"

'mailcowdockerized_postfix-mailcow_1' base images out of date (current version 18.04.2 LTS) Debian Version: buster/sid PRETTY_NAME="Ubuntu 18.04.1 LTS"

'mailcowdockerized_sogo-mailcow_1' base images out of date (current version 9.9) Debian Version: 9.6 PRETTY_NAME="Debian GNU/Linux 9 (stretch)"

'mailcowdockerized_clamd-mailcow_1' base images out of date (current version 9.9) Debian Version: 9.6 PRETTY_NAME="Debian GNU/Linux 9 (stretch)"

'mailcowdockerized_dovecot-mailcow_1' base images out of date (current version 9.9) Debian Version: 9.6 PRETTY_NAME="Debian GNU/Linux 9 (stretch)"

#####################################################################

'mailcowdockerized_php-fpm-mailcow_1' base images up to date Alpine Version: 3.9.4 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_nginx-mailcow_1' base images up to date Alpine Version: 3.9.4 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_ipv6nat-mailcow_1' base images up to date Alpine Version: 3.9.4 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_memcached-mailcow_1' base images up to date Alpine Version: 3.9.4 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_redis-mailcow_1' base images up to date Alpine Version: 3.9.4 PRETTY_NAME="Alpine Linux v3.9"

'mailcowdockerized_mysql-mailcow_1' base images up to date Debian Version: buster/sid PRETTY_NAME="Ubuntu 18.04.2 LTS"

the version was determined with the following commands

docker exec -it mailcowdockerized_X-mailcow_1 sh -c "cat /etc/debian_version" docker exec -it mailcowdockerized_X-mailcow_1 sh -c "cat /etc/alpine-release" docker exec -it mailcowdockerized_X-mailcow_1 sh -c "cat /etc/os-release | grep PRETTY_NAME" if you follow the documentation I always get the outdated Docker Hub versions, I can build the images myself with "docker-compose build", but many won't do that.

Wouldn't an automated creation of images make sense (however, i have no experience with it)? https://docs.docker.com/docker-hub/builds/

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

christianbur commented 5 years ago

I think it's necessary that e.g. postfix/dovecote (with open ports on the internet) are up-to-date, because docker images only get updated when rebuild. Currently postfix-mailcow uses the base image Ubuntu 18.04.1 LTS, so Postfix is on the security level of Ubuntu 18.04.1 LTS and this is not up-to-date.

raoulbhatia commented 5 years ago

I'd also like to add that it is a good thing to NOT have user asks such questions / tools to NOT find such (non-)issues.

What is the reason to not have automated builds? Versioning and breaking existing setups when user docker pull? This should be resolvable by introducing a versioning scheme, shouldn't it?

mkuron commented 5 years ago

I actually agree that automated builds would be desirable. However, we have had occasions in the past where manually rebuilding an image resulted in a broken image due to changes in the base image, changes in package dependencies, or unavailability of some download servers. Also, the versions of packages like Dovecot and Postfix are hard-coded, so updates to them wouldn't be picked up automatically.

Right now, @andryyy rebuilds the images occasionally and tests them before he pushes them. If we want to automate that, we would need some kind of automated testing.

christianbur commented 5 years ago

i just downloaded the current dockerhub images again, the following have been updated in the last days. 

# docker images |grep mailcow
mailcow/watchdog          1.46                3a2f1cf91b3f        25 hours ago        63.1MB
mailcow/phpfpm            1.40                0a18956a411b        36 hours ago        330MB
mailcow/postfix           1.32                a84ae143e304        2 days ago          228MB
mailcow/rspamd            1.43                eee26f86fffe        7 days ago          207MB
mailcow/dovecot           1.78                6af7b63b6d90        10 days ago         444MB

Here are the changes in Github mailcow/watchdog:1.46 mailcow/phpfpm:1.40
mailcow/postfix:1.32 mailcow/rspamd:1.43

Since all these images have been rebuilt in the last days, I would assume that they have a current base image. But this is not the case, why? (Are the base images updated before each manual rebuild of the mailcow images? @andryyy) ?)

watchdog outdated (current 3.9.4)

 # docker exec -it mailcowdockerized_watchdog-mailcow_1 sh -c "cat /etc/alpine-release"
3.9.0
 # docker exec -it mailcowdockerized_watchdog-mailcow_1 sh -c "cat /etc/os-release | grep PRETTY_NAME"
PRETTY_NAME="Alpine Linux v3.9"

php ok (but it use the php base image not the plain alpine 3.9 base image)

 # docker exec -it mailcowdockerized_php-fpm-mailcow_1 sh -c "cat /etc/alpine-release"
3.9.4
 # docker exec -it mailcowdockerized_php-fpm-mailcow_1 sh -c "cat /etc/os-release | grep PRETTY_NAME"
PRETTY_NAME="Alpine Linux v3.9"

postfix outdated (current Ubuntu 18.04.2 LTS)

 # docker exec -it mailcowdockerized_postfix-mailcow_1 sh -c "cat /etc/debian_version"
buster/sid
 # docker exec -it mailcowdockerized_postfix-mailcow_1 sh -c "cat /etc/os-release | grep PRETTY_NAME"
PRETTY_NAME="Ubuntu 18.04.1 LTS"

rspamd outdated (current Ubuntu 18.04.2 LTS)

 # docker exec -it mailcowdockerized_rspamd-mailcow_1 sh -c "cat /etc/debian_version"
buster/sid
 # docker exec -it mailcowdockerized_rspamd-mailcow_1 sh -c "cat /etc/os-release | grep PRETTY_NAME"
PRETTY_NAME="Ubuntu 18.04.1 LTS"
christianbur commented 5 years ago

I think there are two problems when @andryyy creates the mailcow images manually on his computer, this we should try to exclude in the future.

andryyy does a great job, no question, I would only try to make the images more robust and current in the future.

it might also be possible to modify update.sh so that everyone can create their own images locally and they won't be overwritten when you call update.sh again.

christianbur commented 5 years ago

The same problem with the two new images. I understand that you don't want to create images untested automatically, but why are the manually created images created with outdated base images? @andryyy 

# docker images 
mailcow/netfilter             1.26                 924f02300fc4        2 days ago          81MB
mailcow/watchdog              1.47                 b858b14c3a82        2 days ago          63.1MB

# docker exec -it mailcowdockerized_watchdog-mailcow_1 sh -c "cat /etc/alpine-release"
3.9.0
# docker exec -it mailcowdockerized_netfilter-mailcow_1 sh -c "cat /etc/alpine-release"
3.9.0
andryyy commented 5 years ago

Lets update all the extra software in the images for no reason.

I will try to improve this in the future, thanks. Prepare for more surprises and broken images.

andryyy commented 5 years ago

Which vulnerability was fixed?

Am 16.06.2019 um 10:42 schrieb Christian Burmeister notifications@github.com:

For the "current" (1.32) postfix mailcow images (which has open ports to the internet) updates like openssl,libssl are pending. How was it judged that these updates are not necessary?

docker exec -it mailcowdockerized_postfix-mailcow_1 bash

root@mx1:/# apt upgrade Reading package lists... Done Building dependency tree
Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: apt base-files bash bsdutils debconf e2fsprogs fdisk gcc-8-base libapt-pkg5.0 libblkid1 libcom-err2 libext2fs2 libfdisk1 libgcc1 libglib2.0-0 libgnutls30 libmount1 libpam-modules libpam-modules-bin libpam-runtime libpam0g libpython2.7-minimal libpython2.7-stdlib libseccomp2 libsmartcols1 libss2 libssl1.1 libstdc++6 libsystemd0 libudev1 libunistring2 libuuid1 login mount openssl passwd python2.7 python2.7-minimal tar util-linux 40 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 15.4 MB of archives. After this operation, 712 kB of additional disk space will be used. Do you want to continue? [Y/n] n — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

christianbur commented 5 years ago

You say there's no reason or it make zero sense to update, not me. So you should know the answers to the questions, not me.

raoulbhatia commented 5 years ago

For example, Ubuntu 18.04 LTS saw an upgrade from openssl 1.1.0g-2ubuntu4.3 to openssl 1.1.1-1ubuntu2.1~18.04.2.

The OpenSSL 1.1.1 release includes support for TLSv1.3, see https://wiki.openssl.org/index.php/TLS1.3

However, I do not know if this is already part of the official Ubuntu base images or would be pulled automatically when installing the packages.

@andryyy I understand the approach to not upgrade for the sake of upgrading. However, I also see value in making sure that a release of a docker image is based off of the latest, supported base image. It will give people more confidence and will reduce support requests like this one.

Perhaps a new versioning schema and a CI/CD pipeline that handles regression testing will combine the best of two worlds?

christianbur commented 5 years ago

@andryyy I think the ignorance of security updates is slowly becoming a real security issue. 

root@nuc0:/data/docker_projects/mailcow-dockerized# docker exec -it mailcowdockerized_dovecot-mailcow_1 bash
root@mx10:/# apt-get upgrade -s | grep -i security
Inst libapt-pkg5.0 [1.4.8] (1.4.9 Debian:9.9/oldstable, Debian-Security:9/oldstable [amd64])
Conf libapt-pkg5.0 (1.4.9 Debian:9.9/oldstable, Debian-Security:9/oldstable [amd64])
Inst apt [1.4.8] (1.4.9 Debian:9.9/oldstable, Debian-Security:9/oldstable [amd64])
Conf apt (1.4.9 Debian:9.9/oldstable, Debian-Security:9/oldstable [amd64])
Inst libsystemd0 [232-25+deb9u6] (232-25+deb9u11 Debian:9.9/oldstable, Debian-Security:9/oldstable [amd64])
Conf libsystemd0 (232-25+deb9u11 Debian:9.9/oldstable, Debian-Security:9/oldstable [amd64])
Inst libudev1 [232-25+deb9u6] (232-25+deb9u11 Debian:9.9/oldstable, Debian-Security:9/oldstable [amd64])
Conf libudev1 (232-25+deb9u11 Debian:9.9/oldstable, Debian-Security:9/oldstable [amd64])
Inst libssl1.0.2 [1.0.2r-1~deb9u1] (1.0.2s-1~deb9u1 Debian-Security:9/oldstable [amd64])
Inst libssl1.1 [1.1.0j-1~deb9u1] (1.1.0k-1~deb9u1 Debian-Security:9/oldstable [amd64])
Inst dnsutils [1:9.10.3.dfsg.P4-12.3+deb9u4] (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64]) []
Inst bind9-host [1:9.10.3.dfsg.P4-12.3+deb9u4] (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64]) []
Inst libisc160 [1:9.10.3.dfsg.P4-12.3+deb9u4] (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64]) []
Inst libdns162 [1:9.10.3.dfsg.P4-12.3+deb9u4] (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64]) []
Inst libisccc140 [1:9.10.3.dfsg.P4-12.3+deb9u4] (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64]) []
Inst libisccfg140 [1:9.10.3.dfsg.P4-12.3+deb9u4] (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64]) []
Inst liblwres141 [1:9.10.3.dfsg.P4-12.3+deb9u4] (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64]) []
Inst libbind9-140 [1:9.10.3.dfsg.P4-12.3+deb9u4] (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64])
Inst libexpat1 [2.2.0-2+deb9u1] (2.2.0-2+deb9u2 Debian-Security:9/oldstable [amd64])
Inst linux-libc-dev [4.9.168-1] (4.9.168-1+deb9u3 Debian-Security:9/oldstable [amd64])
Inst openssl [1.1.0j-1~deb9u1] (1.1.0k-1~deb9u1 Debian-Security:9/oldstable [amd64])
Conf libssl1.0.2 (1.0.2s-1~deb9u1 Debian-Security:9/oldstable [amd64])
Conf libssl1.1 (1.1.0k-1~deb9u1 Debian-Security:9/oldstable [amd64])
Conf dnsutils (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64])
Conf bind9-host (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64])
Conf libisc160 (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64])
Conf libdns162 (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64])
Conf libisccc140 (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64])
Conf libisccfg140 (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64])
Conf liblwres141 (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64])
Conf libbind9-140 (1:9.10.3.dfsg.P4-12.3+deb9u5 Debian-Security:9/oldstable [amd64])
Conf libexpat1 (2.2.0-2+deb9u2 Debian-Security:9/oldstable [amd64])
Conf linux-libc-dev (4.9.168-1+deb9u3 Debian-Security:9/oldstable [amd64])
Conf openssl (1.1.0k-1~deb9u1 Debian-Security:9/oldstable [amd64])

root@mx10:/# cat /var/log/apt/history.log 
Start-Date: 2019-05-05  17:23:11

For example, Dovecote has not received any updates since 05-05-2019. So far there is still no explanation why these security updates are not considered relevant.

For every security update listed above, andryyy should give a reason why there is "no reason" to update.

All other containers don't look much better. Even with new containers (olefy) the current base image (Alpine 3.9.4) is ignored and the outdated local base image (Debian 3.9.0) is used instead. I can well understand that new major releases (e.g. Alpine 3.9 -> 3.10, Debian 9 -> 10) are used with caution, but I can't understand this with security updates.

There is an urgent need for action!!!!

andryyy commented 5 years ago

Please tell me how this affects the services we expose. You skipped that part. Why would I need to answer that myself? oO

Alpine 3.9 has support until 2020-11-01 btw. I will update all of them to 3.10 in the future.

I will update the images in the next hours...

christianbur commented 5 years ago

I can't tell you exactly what the problem is in openssl, but it has been classified as security relevant by Debian. For a secure operation of services on the internet you should install safty updates promptly, at Docker this means unfortunately creating a new image.

The problem is also not the major release Alpine 3.9 (I don't have a problem with that), the problem is that there are no updates and Alpine 3.9.0 is still used and not the current version 3.9.4. Because in my opinion 3.9.0 has no support until 2020-11-01. Also the update to Alpine 3.10 will not solve the problem if you stay on 3.10.0 for months.

christianbur commented 5 years ago

Sorry for my insistence, you're doing a great job. I just want to avoid that we cause problems in the future by such a neglect in all Mailcow instances.

christianbur commented 5 years ago

@andryyy thanks for the updates of the images.

What I again don't understand is why the obsolete local base image was used again. If the base images on the build computer had been current, (almost) all images would have to use Alpine 3.9.4 and Debian 9.9 and 18.04.2 now, unfortunately this is not the case.

The dot releases are only bugfix releases (alpine 3.9.0-4, debian 9.0-9, ubuntu 18.04.1-2) that contribute to the stability of the system, why aren't they used? I just don't get it.

I downloaded the new images with ./update.sh 

# docker images
REPOSITORY                TAG                 IMAGE ID            CREATED             SIZE
mailcow/dovecot           1.81                3462248d17c8        19 hours ago        444MB
mailcow/unbound           1.7                 bc23f7647ee9        19 hours ago        20.8MB
mailcow/sogo              1.54                e2ef7c5bcdee        19 hours ago        488MB
mailcow/postfix           1.35                4765e79ec8a6        19 hours ago        228MB
mailcow/olefy             1.0                 d2a6e6e934d2        19 hours ago        89.5MB
mailcow/clamd             1.26                45e6da27c528        19 hours ago        286MB
mailcow/watchdog          1.48                ccfff974abc2        20 hours ago        63.1MB
mailcow/solr              1.5                 34c72ee3af40        20 hours ago        303MB
mailcow/rspamd            1.45                a70b7d14db2e        20 hours ago        207MB
mailcow/phpfpm            1.42                55c88078e68a        20 hours ago        330MB
mailcow/netfilter         1.27                4696e8e61870        20 hours ago        81MB
mailcow/dockerapi         1.30                1b77d4c59d63        20 hours ago        73.4MB
mailcow/acme              1.58                7ac93498e351        20 hours ago        106MB

I check the versions of the new images, it looks like this:

# mailcow container #########################################
             Alpine Linux v3.10"--3.10.0 -- ["'mailcowdockerized_memcached-mailcow_1'", "'mailcowdockerized_redis-mailcow_1'"]
               Alpine Linux v3.9"--3.9.0 -- ["'mailcowdockerized_acme-mailcow_1'", "'mailcowdockerized_dockerapi-mailcow_1'", "'mailcowdockerized_netfilter-mailcow_1'", "'mailcowdockerized_olefy-mailcow_1'", "'mailcowdockerized_unbound-mailcow_1'", "'mailcowdockerized_watchdog-mailcow_1'"]
               Alpine Linux v3.9"--3.9.2 -- ["'mailcowdockerized_solr-mailcow_1'"]
               Alpine Linux v3.9"--3.9.4 -- ["'mailcowdockerized_ipv6nat-mailcow_1'", "'mailcowdockerized_nginx-mailcow_1'", "'mailcowdockerized_php-fpm-mailcow_1'"]
      Debian GNU/Linux 9 (stretch)"--9.6 -- ["'mailcowdockerized_clamd-mailcow_1'", "'mailcowdockerized_dovecot-mailcow_1'", "'mailcowdockerized_sogo-mailcow_1'"]
         Ubuntu 18.04.1 LTS"--buster/sid -- ["'mailcowdockerized_postfix-mailcow_1'", "'mailcowdockerized_rspamd-mailcow_1'"]
         Ubuntu 18.04.2 LTS"--buster/sid -- ["'mailcowdockerized_mysql-mailcow_1'"]

If I create the images myself with "docker-compose build --pull --no-cache", it looks like this. Therefore, in my opinion, there is something wrong with the creation of the images. 

# mailcow container #########################################
             Alpine Linux v3.10--3.10.0 -- ["'mailcowdockerized_memcached-mailcow_1'", "'mailcowdockerized_redis-mailcow_1'"]
               Alpine Linux v3.9--3.9.4 -- ["'mailcowdockerized_acme-mailcow_1'", "'mailcowdockerized_dockerapi-mailcow_1'", "'mailcowdockerized_ipv6nat-mailcow_1'", "'mailcowdockerized_netfilter-mailcow_1'", "'mailcowdockerized_nginx-mailcow_1'", "'mailcowdockerized_olefy-mailcow_1'", "'mailcowdockerized_php-fpm-mailcow_1'", "'mailcowdockerized_solr-mailcow_1'", "'mailcowdockerized_unbound-mailcow_1'", "'mailcowdockerized_watchdog-mailcow_1'"]
      Debian GNU/Linux 9 (stretch)--9.9 -- ["'mailcowdockerized_clamd-mailcow_1'", "'mailcowdockerized_dovecot-mailcow_1'", "'mailcowdockerized_sogo-mailcow_1'"]
         Ubuntu 18.04.2 LTS--buster/sid -- ["'mailcowdockerized_mysql-mailcow_1'", "'mailcowdockerized_postfix-mailcow_1'", "'mailcowdockerized_rspamd-mailcow_1'"]

Some images use a current base image, but these are external images (php, ipv6nat, nginx, memcached, redis, ...). Now the old base images are provided with updates, but the base images themselves are still obsolete.

andryyy commented 5 years ago

I don't give a fuck to always use the latest Alpine or Ubuntu while the distro is still in support. I will not update to Alpine 3.10 without testing. There is no fucking benefit. Please stop it now.

We are on an updated Alpine 3.9. I don't give a fuck if the base is 3.9 and we upgrade it to latest or if the base is 3.9.4 and we upgrade it from there to the same patch level. The result is the same.

I will not switch to Buster or Alpine 3.10 without tests, no way. Alpine 3.9 is supported until 11/2020! Stretch is LTS in 2020 and gets support until 2022!

I don't care if Alpine does not increase the stupid alpine-version counter when running apk update. I don't care if it says 3.9.0 or 3.9.4, when the results are the same.

There is so much I don't care about.

It was a mistake to not update the images for so long, yes! I will change that in the future. But this is just ridiculous now.

mkuron commented 5 years ago

@christianbur, please check whether there is any difference in the versions of the installed packages (not the base images) between the images you built and the ones @andryyy built. Given @andryyy‘s explanation, I would expect them to be the same (if they are not, there is probably an apt-get upgrade or apk update missing in a Dockerfile). That is sufficient to be up to date, the base image version does not matter.