Skip to content

chore(release): 0.5.0 - #39

Merged
MotherSphere merged 1 commit into
mainfrom
release/0.5.0
Sep 6, 2026
Merged

chore(release): 0.5.0#39
MotherSphere merged 1 commit into
mainfrom
release/0.5.0

Conversation

@MotherSphere

Copy link
Copy Markdown
Member

Version bump for 0.5.0, carrying the measurement and the security round from #38.

Minor rather than patch, on purpose. A hostname the daemon did not confirm against the address no longer satisfies an allow --dst-host. On a host running the DNS observer most names come from observed answers, so such a rule may stop matching where it used to — it stands aside and the rules beneath it answer, and deny --dst-host is unchanged. docs/HARDENING.md explains why. Two smaller behaviour changes ride with it: enforcing now answers about the nftables table rather than about whether a packet was ever seen, and a rule scoped to a digest the daemon cannot compute abstains instead of falling through to a lower allow.

Every hardcoded version moves together — Cargo.toml, both lock files, pkg/PKGBUILD, pkg/colony.json (field and asset name), the RPM spec and its %changelog, pkg/README.md. The kernel crate's own lock is included because check-versions.sh learned to guard it this round, after the 0.3.0 and 0.4.0 bumps had both silently skipped it.

Both release guards pass locally, the binaries report 0.5.0, 17 test suites green, clippy clean with -D warnings in both feature configurations.

A minor bump, not a patch, and the reason is behaviour rather than API:
a hostname the daemon did not confirm against the address no longer
satisfies an `allow --dst-host`. On a host running the DNS observer most
names come from observed answers, so an allow rule written against a
name may stop matching where it used to. It stands aside rather than
failing open - the rules beneath it answer - and a `deny --dst-host` is
unchanged. Anyone leaning on a hostname allow rule should read the
`dst_host` section of docs/HARDENING.md before upgrading.

Two smaller ones in the same direction: `cfc status`'s `enforcing` now
answers about the nftables table rather than about whether a packet was
ever seen, so a machine whose ruleset was removed stops reporting yes;
and a rule scoped to a digest the daemon cannot compute now abstains
instead of handing the flow to a lower-precedence allow.

Everything the release guards cover moves together, including the
kernel crate's own lock file - which `check-versions.sh` learned about
this round precisely because the 0.3.0 and 0.4.0 bumps had both left it
behind.
@MotherSphere
MotherSphere merged commit fa9efc3 into main Sep 6, 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