Skip to content

chore(release): 0.4.0 - #37

Merged
MotherSphere merged 4 commits into
mainfrom
release/0.4.0
Sep 5, 2026
Merged

chore(release): 0.4.0#37
MotherSphere merged 4 commits into
mainfrom
release/0.4.0

Conversation

@MotherSphere

Copy link
Copy Markdown
Member

Version bump for 0.4.0, the release that carries the fast-allow path (#36) plus what landed on main beside it since v0.3.0 (#35, #34, dependency bumps).

Every hardcoded version moves together: Cargo.toml, Cargo.lock, pkg/PKGBUILD, pkg/colony.json (field and asset name), the RPM spec and its %changelog, pkg/README.md. scripts/check-versions.sh and scripts/check-release-assets.sh pass locally; the binaries report 0.4.0.

The v0.4.0 tag follows the merge; release.yml refuses a tag that does not match [workspace.package].

One feature has been on main since v0.3.0 with nothing to release it: the
fast-allow path (#36), opt-in and off by default, with the eBPF ABI at v4
- a minor bump. Beside it: the guard that holds the RPM spec to Cargo.toml
on every push (#35), a test race fix (#34) and five dependency bumps.

The CHANGELOG's [Unreleased] section was written as the branch went; it
becomes 0.4.0 as it stands, plus entries for what landed on main next to
it. Every place the version is hardcoded moves together - Cargo.toml, the
lock, the PKGBUILD, the Colony manifest and its asset name, the RPM spec
and its %changelog, pkg/README's build snippet - and both release guards
pass locally. The release workflow refuses a tag that does not match
[workspace.package], so the tag follows this commit.
The Internals bullet said the ETXTBSY fix staged the copy out of reach of
other forks. e9d7e19 did no such thing: it serialises copy and spawn
behind one lock, so the fork-to-exec window of one test no longer
overlaps the other's write. A changelog line written from memory is the
class of mistake TODO.md section 6 already records; this one was caught
before the tag.
…kipped a third time

crates/cfc-ebpf is its own workspace with its own committed Cargo.lock,
and nothing builds it with --locked, so a bump that regenerated the root
lock left this one saying 0.3.0 in a 0.4.0 tree. The 0.3.0 release had
done the same (its lock said 0.2.3 until the fast-allow merge moved it in
passing). The first build of the tag would have rewritten the file and
left the checkout dirty; a --locked build of the crate would have refused.

The one line moves, and scripts/check-versions.sh now holds the
`cfc-ebpf-common` entry of that lock to [workspace.package] with the
others - checked on every push and again at tag time by release.yml.
Proven to fail on a lock left behind before being trusted to pass.
…hen the layer loads

The changelog and the architecture doc promised the nftables set is
flushed unconditionally at every start, so that a daemon that crashed
while armed cannot leave its predecessor's mark accepted. The flush lived
at the top of load_and_attach, which a daemon started with `[ebpf]
enabled = false`, or built without the layer, never reaches - and the set
outlives daemons. In that one configuration the promise was false and the
stale element was a standing bypass token for any process that had once
read the value off its own socket.

`ebpf::flush_stale_fast_allow` does the flush for those two starts: main
calls it when the layer is switched off in the config, the no-feature
branch of `start` calls it itself. Not under --dry-run, which touches
nothing by definition and runs unprivileged in the smoke test, where a
warning from this module is a failure. A table that is not loaded yet is
already a silent success in `flush`, so a boot before the nft unit stays
quiet. The normal path is unchanged: the loader still flushes first.

Found by the release critique, reading the changelog against the code.
@MotherSphere
MotherSphere merged commit dc39346 into main Sep 5, 2026
31 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant