Skip to content

kuma v0.11.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 18 Aug 21:58
v0.11.0
54868cc

The media is a download. v0.10.0 built the ISO in CI and booted it on every push to prove it could, and left attaching it to a release switched off until that job had a history rather than a first day; it has one, so a release now carries the thing you write to a USB stick. The walkthrough leads with it, because "describe a machine, build an image, then make your own media" was the order a project with nothing to download had to teach.

One thing the release also fixes is the assertion that guards v0.10.0's signature policy, which could not see the policy going missing.

Added

  • Releases carry the live ISO. A tag builds it, boots it, signs it with Sigstore like every other release asset, and attaches it to the release that already exists, so downloading kuma and installing kuma are the same page. Booting it is not a formality: the same script CI runs starts the ISO under UEFI and asks the live session whether it reached a desktop, so the file on the release page is one that came up rather than one that built. This was wired in v0.10.0 and left off, waiting on the job that builds it having a run history rather than on a tag being its first real exercise; ci.yml has built and booted the ISO on every push to main and on a daily cron since, and went green before this was turned on.

Fixed

  • The install-and-boot smoke tests could not see a missing signature policy. They asserted that kuma doctor reports nothing graded fail, and the three ways this control goes missing are all graded warn: no policy file, one that will not parse, or one that does not name kuma's repository. Only a policy naming a key it does not have, or one with nowhere to look for signatures, was ever fail. So the scan saw the half-broken states and was blind to the absent one, which is the likeliest of the three and the one an /etc merge can cause. An installed machine now has to grade signatures as ok, which is the requirement rather than "not fail" because every image writes the policy, the key and the registries.d entry unconditionally. The cross-version job reports whether upgrading brings the policy to a machine installed before it existed, and fails only if an upgrade takes it away.

Changed

  • The getting-started walkthrough leads with installing a machine rather than building an image. It was ordered "build an image, then build media" because media was something you had to make yourself, and it said so; with media on the release page the front door is download, boot, install, and describing your own machine is what you do next rather than what you do first. The builder's path is unchanged and still there, one step later.

Static x86_64 binary, no runtime dependencies.

$ curl -LO https://github.com/Letdown2491/kuma-linux/releases/download/v0.11.0/kuma-x86_64-unknown-linux-musl
$ chmod +x kuma-x86_64-unknown-linux-musl && sudo mv kuma-x86_64-unknown-linux-musl /usr/local/bin/kuma

Verify it came from this workflow:

$ cosign verify-blob \
    --bundle kuma-x86_64-unknown-linux-musl.bundle \
    --certificate-identity-regexp '^https://github.com/Letdown2491/kuma-linux/' \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    kuma-x86_64-unknown-linux-musl

Built from 54868ccd411d0ebebe38ef7c689f3f8941e28352.

Assets 8
Loading