Nothing showed where a published image or download came from, and the
standalone tarballs had no checksum at all. Anyone who could swap a
release asset could swap its `.sha256` with it.
- every published image (release, `-always`, beta/dev and Lite) gets a
signed build provenance attestation, pushed to GHCR next to it
- the Lite zips and standalone tarballs are attested as well
- standalone tarballs get a `.sha256`, like the Lite zips
- the tarball build no longer holds a write token: a separate release
job, which runs no checked-out code, checksums, attests and uploads
- the README says how to check with `gh attestation verify`
A manual run of the release image workflow tagged `latest` on whatever
ref it was dispatched from, and the demo deploy and every Watchtower
install follow `latest`. It now moves only for a published stable
release or a dispatch on a stable `v*` tag.
- `static-lite.yml` gave the whole workflow `contents: write`, including
the build job that runs pull-request code. The build is read-only
now; a separate release job with no checkout uploads the zips.
- `docker-publish.yml` passes the ref name through `env` instead of
interpolating it into the shell script.
Add GitHub Actions workflow to automatically build and publish Docker
images to ghcr.io on releases. Supports amd64 and arm64 architectures.
Pre-built image available at ghcr.io/root-fr/jmap-webmail.
Linus Rath
Linus Rath
xnilsit
Matthieu MALVACHE