Skip to content

WireMesh v0.10.1

Choose a tag to compare

@github-actions github-actions released this 25 Aug 17:06
· 163 commits to main since this release
Immutable release. Only release title and notes can be modified.
v0.10.1
e80ebe2

v0.10.0 was tagged but never published: its Release workflow failed in
the linux-binaries jobs because deploy/docker/Dockerfile ran an unpinned
cargo install bpf-linker, upstream released 0.11.0 (which links against
system LLVM), and rust:1-bookworm ships no llvm-config. Nothing in this
repo had changed -- the same content built green two days earlier. This
release pins bpf-linker to 0.10.4 (the version the dev container carries
and the whole test suite is proven against) in both Dockerfiles, and is
otherwise v0.10.0. Its notes follow, and they apply in full.

Note for CI: container-images.yml restores a cached builder layer, so it
never re-ran the install and stayed green; only the cold build in
release.yml reaches that line. The failure mode is invisible until a
release. (Tracked under B4 in the v1.0 release-scope inventory.)

v0.10.0 — automatic key rotation is opt-in; every artifact reports its real version

BEHAVIOUR CHANGE, read before upgrading. An absent WIREMESH_ROTATION_INTERVAL
used to mean "rotate every gateway every 30 days". It now means NO TIMER.
Automatic key rotation is opt-in in every deployment path -- .deb/.rpm,
container image, and source build alike. If you were relying on the old
default, this upgrade silently stops rotating and you must set an explicit
interval to get it back.

Why: the timer pointed at a known-open defect (BACKLOG item 9, the rotation
wedge). A rotation that fails part-way parks a gateway's state machine
off-idle, and that gateway then silently ignores every later rotation until
its process restarts, never scrubbing the old key. The schedule is what makes
that fabric-wide. Explicit intervals, off, and every malformed-value
rejection are unchanged.

Know before you arm it: on-demand rotation has NO CLI. The Admin RotateKey
RPC exists and works, but fabricctl does not wrap it, so triggering a
rotation means a hand-rolled gRPC call against an Admin service that binds
loopback-only by design -- from the controller host. Earlier releases
documented fabricctl rotation as the supported path; that was never true.
Tracked as BACKLOG item 33.

FIXED: every published container image reported 0.1.0. container-images.yml
never invoked scripts/set-version.sh, so controller, gateway, relay,
fabricctl and operator images all self-reported the placeholder on every
release. Binaries and packages were always stamped correctly. This is the
first release whose images report their real version. set-version.sh also
gained wiremesh-operator, which it had never stamped.

Also: the README described a project three cycles stale and linked to
neither install guide; the spike/ directory (8 throwaway Phase-0 crates,
8 of 10 open Dependabot alerts) is deleted; and the controller --help
DEPLOYMENT block, wrong three ways since v0.8.0, is corrected.

What's Changed (since v0.9.2 — v0.10.0 was never published)

  • fix(controller): automatic key rotation is now opt-in everywhere by @zozo6015 in #73
  • fix(release): stamp the version into every shipped artifact by @zozo6015 in #74
  • docs: rewrite the README, delete spike/, fix the manual-rotation claim by @zozo6015 in #75
  • fix(build): pin bpf-linker to 0.10.4, unbreaking the release build by @zozo6015 in #76

Full Changelog: v0.9.2...v0.10.1