fabriziosalmi/certmate v2.47.1

v2.47.1 (a base image a month newer, and a release that will not ship an old one)

on GitHub

v2.47.1 (a base image a month newer, and a release that will not ship an old one)

A patch release with no change to CertMate's own code. The image is rebuilt on the current python:3.12-slim-trixie, which removes 54 of the 308 findings Trivy reported on 2.47.0 and adds none (#403). The release process now refuses to ship a base image that has fallen behind, so the same drift cannot build up again unnoticed. The API contract stays at 2.39.

Read this before upgrading

Nothing to do. The Python packages in the image are the same as in 2.47.0, byte for byte (the same pip freeze; certbot 5.8.0, cryptography 50.0.2), and the configuration, the data directory and the API do not change. What changes comes with the base image: Debian 13.6 becomes 13.7, and the Python interpreter 3.12.14 becomes 3.12.15.

If you build your own image from the Dockerfile, its two FROM lines now pin python:3.12-slim-trixie@sha256:dddfd7e0….

Changed

• The image is built on the current base. The Dockerfile pins its base by digest, on purpose: a rebuild gives the same bytes. The cost is that nothing moves the pin, and the one in 2.47.0 was 31 days old. Rebuilt on the digest the tag points at today, with nothing else changed, Trivy reports 254 findings instead of 308 (high: 53 instead of 65). The 54 that go are all in Debian packages (12 high, 35 medium, 7 low), and no new one appears. Of the 254 that remain, 50 are in curl and libcurl4t64. They stay: the image's own health check runs curl, and so do deploy hooks (docs/deploy-hooks.md).
• A release now checks its base image. scripts/release.sh prepare refuses a release when the pinned digest is behind the tag and older than two weeks (scripts/check_base_image.py). A pin the tag has not moved past is accepted at any age; a pin that is behind but recent is accepted too, because the base is rebuilt about weekly. The fix is one command, scripts/check_base_image.py --update, and --allow-stale-base "reason" ships anyway and logs why. See "The base image" in CONTRIBUTING.md.
• The Akamai Edge DNS plugin stays at 0.1.0, and a test now runs it (#1079). certbot-plugin-edgedns 0.3.0 reads the credentials file without the edgedns_ prefix that CertMate writes, declares Python 3.12 or later (every other package pinned in requirements.lock accepts 3.11), and adds only the Akamai account switch key, which CertMate does not expose. So the pin stays. The test that guarded the credentials format used to reproduce how 0.1.0 reads the file without importing the plugin, and it passed with 0.3.0 installed. It now has the installed plugin read the file CertMate writes.

How it was checked

• Findings. Trivy (--scanners vuln) on the published fabriziosalmi/certmate:2.47.0 and on this release's image built from 33f47fe, which differs from the release only by these notes and the version bump: 308 and 254, compared finding by finding (54 removed, 0 added).
• The image is the same apart from the base. In both images: the same pip freeze hash, the same certbot, cryptography and edgedns versions, pip check clean.
• Real certificates. The real-certificate gate (Let's Encrypt staging, DNS-01 through Cloudflare) passed 24 of 24 against this image, in 7 minutes. scripts/release.sh prepare runs it again before the release is cut.
• The release check. Run on the Dockerfile of 2.47.0, it refuses it (pin 31 days old, behind the tag) and exits 1; with --allow-stale it passes and prints the reason. Run on this release's Dockerfile, it passes: the tag has not moved past the pin. 17 tests cover the decision without a network.
• The edgedns test. It passes with 0.1.0 installed and fails with 0.3.0 installed, in an environment built from requirements.lock.