Active maintenance?

[jasonhildebrand]

Hi, thanks for sharing this project. I have been using namshi/docker-smtp but have noticed it is no longer being maintained
(there was response to request for providing an updated image with important exim4 security updates namshi/docker-smtp#81)

I'm wondering if you are able and intend to actively maintain this project? If so, I would switch and will encourage others to do so as well. I would also consider becoming a co-maintainer to help push out security updates when needed.

[tlex]

Thanks for your question. In fact, the image with the :dev-mastertag gets rebuilt every week (see also https://gitlab.com/ix.ai/smtp/-/pipelines).

The :latest tag gets rebuilt every time a new git tag gets created. I'll do so now, even though no changes have been made to the codebase.

I would be happy to add one more maintainer to it - even happier to automate the security updates 🙂

[jasonhildebrand]

Thanks for the info. My gitlab handle is @jasonhildebrand if you want to add me to the project as a maintainer.

One question I have is how to ensure that upstream security fixes (from debian) get included in a new build. I am not familiar with buildx, but I see you have enabled build caching.

The following output is from https://gitlab.com/ix.ai/smtp/-/jobs/1567592267

#12 [linux/arm/v6 2/3] RUN set -xeu; export DEBIAN_FRONTEND=noninteractive; export TERM=linux; apt-get update; apt-get -y dist-upgrade; apt-get install -y --no-install-recommends exim4-daemon-light iproute2 ; apt-get -y --purge autoremove; apt-get clean; rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* /var/cache/* ; find /var/log -type f | while read f; do echo -ne '' > $f; done
#12 sha256:e4ae234be6553b8657e707b9762194bf10abe5ec6ec6c3d38c5e25bc4d88cc78
#12 CACHED

If I understand correctly, this step is being produced from the cache, so it's not actually fetching the latest exim version (or other dependencies) from debian. Maybe we need to disable caching to ensure that the latest upstream security fixes get included?

[tlex]

I've checked now and the cache in that job has been created in the previous step - the relevant job is https://gitlab.com/ix.ai/smtp/-/jobs/1563510215:

docker buildx build --platform=linux/amd64,linux/arm64,linux/arm/v7,linux/arm/v6,linux/386 --progress=plain --cache-from=registry.gitlab.com/ix.ai/smtp:cache --cache-to=registry.gitlab.com/ix.ai/smtp:cache --build-arg CI_COMMIT_REF_NAME=master --build-arg CI_PIPELINE_ID=365355532 --build-arg CUSTOM_VERSION=none --pull --tag=registry.gitlab.com/ix.ai/smtp:dev-master --tag=ixdotai/smtp:dev-master --push .

Due to the fact that the base image was changed since the last successful build (in Dockerfile on L1: FROM debian:stable-slim, the cache has been automatically invalidated.

I will add to the Dockerfile an ARG for the CI_PIPELINE_ID (it will be enough to have it there without using it), this will invalidate the cache every time - since the value changes at every single run. It's a lot easier than changing the pipeline file common.yml that's shared across projects.

One additional note: with great power comes great responsibility. You have now the permission to merge to master and to create vXXX tags.

[jasonhildebrand]

OK, thanks for looking into the caching issue. Invalidating the cache will make the CI slower, but it's the right decision.

Point taken re: responsibility. My interest in maintainership is to ensure that there is not a single point of failure (e.g. if you become busy or unavailable). I subscribe to debian-security so I will be aware if there are exim updates.