search

ix-ai / smtp

This is a SMTP docker container for sending emails. You can also relay emails to gmail and amazon SES.
MIT License
92 stars 14 forks source link

Active maintenance? #4

Closed jasonhildebrand closed 3 years ago

jasonhildebrand commented 3 years ago

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 https://github.com/namshi/docker-smtp/issues/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 commented 3 years ago

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 :slightly_smiling_face:

jasonhildebrand commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.