Skip to content

v0.6.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 20 Oct 06:57
· 103 commits to main since this release
v0.6.0
67f16ce
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Changelog

Two things that live on the machine. A pruned release's images now leave the
store with it, on release prune and on dev mode's automatic prune, so a dev
machine following a channel no longer fills its disk one build's images at a
time. And a secret can be given to the user its container runs as, so an image
that does not run as root reads its Compose file secret without user: "0:0".

Upgrading changes no schema: the installation stays at 12, and a bundle built
for 0.5.0 installs unchanged. Three things behave differently:

  • The first prune after upgrading also removes the images of the releases it
    prunes. It removes only names that no release left on the machine uses, in
    any installation, and never forces a removal. While any release directory
    on the machine cannot be read, it removes no image at all. Images left by
    earlier prunes stay; the release prune reference says how to clear them
    by hand.
  • release prune takes the deployment lock. A script that runs it while an
    update of the same installation holds the lock is now refused with exit 4,
    unless it passes --wait.
  • A bundle whose secret schema declares owner needs
    compatibility.min_manager_version: "0.6.0", and a manager running as root
    to apply it. A manager on macOS refuses owner, and user-namespace
    remapping and rootless Docker are not handled.

The JSON changes are additive: release prune --json gains dry_run and
images, and secret render --json gains uid and gid.

Added

  • release prune removes the images of the releases it prunes. A release directory went and every image the runtime pulled or loaded for it stayed, so a dev machine following a channel, which prunes after every update, filled its disk one build's images at a time. The pruned releases' images now go with them, on both release prune and dev mode's automatic prune. A name stays when any release left on the machine, in any installation and whatever its role, still names it; spellings the daemon treats as one name, such as postgres@sha256:… and docker.io/library/postgres@sha256:…, count as one. Nothing is forced: a name a container uses is reported as kept, and the prune still succeeds. If any release directory on the machine cannot be read, no image is removed and the report names the directory. Images left by earlier prunes are not reclaimed; the release prune reference says how to clear them by hand.
  • A secret can be given to the user its container runs as. Every rendered secret was 0400 and the manager's, which is root, and Compose ignores uid, gid and mode on a file secret, so a service whose image runs as another user, as distroless and most hardened images do, could not read the secret it was given. A declaration in the secret schema now takes owner: "65532" or "65532:65532", numeric only, and every render gives the file to that user: apply, an update and its restore, secret render, and a rotation. The mode stays 0400 and the directory 0700. A manager that cannot give the file away refuses with exit 6, naming the secret, rather than render a file the container is refused; a manager on macOS refuses every owner for now. A schema using owner needs compatibility.min_manager_version: "0.6.0", so an older manager says it is too old. secret render and its --json show each file's owner as uid and gid.

Changed

  • release prune takes the deployment lock, so it waits for or refuses beside an update of the same installation, and honours --wait. Its --json output gains dry_run, without which a plan and an act read the same, and images with what was removed, what was kept and why, and why removal was skipped.

Installing this release

curl -fsSL https://morzecrew.github.io/morzer/install.sh | sh -s -- --version 0.6.0

The script verifies the checksum always and the signature whenever
minisign is present; --require-signature makes a missing minisign fatal,
which is what a production runbook sets. --print-only shows everything it
detected and would do, and changes nothing. install.sh is an asset of this
release and is covered by SHA256SUMS below.

Verifying this release by hand

ARCHIVE=morzer_0.6.0_linux_amd64.tar.zst   # the one you downloaded

curl -fsSLO https://raw.githubusercontent.com/morzecrew/morzer/main/morzer.pub
minisign -Vm SHA256SUMS -p morzer.pub
grep " ${ARCHIVE}$" SHA256SUMS | sha256sum -c -

SHA256SUMS covers every architecture, so checking it whole fails on the
archives you did not download — and --ignore-missing, the usual way
around that, reports OK when no archive is present at all. Pulling out
the line for the file you have fails when there is nothing to check.

The signing key is the same for every release. If you have verified a
morzer release before, use the copy you already have rather than fetching
it again — a key that changes between releases is the thing worth noticing.

Release bundles are a separate artifact with their own signature and their
own key; see
https://morzecrew.github.io/morzer/reference/release-commands/#verification

Assets 7
Loading