Skip to content

cfctl v1.2.0

Choose a tag to compare

@rogu3bear rogu3bear released this 19 Jul 22:11
· 677 commits to main since this release
caa581e

Unsigned release; integrity is by checksum. Verify against SHA256SUMS before use.

New governed capabilities

This release closes the largest structural gap the prior audit surfaced: teardown and lifecycle operations that were catalogued but not executable, so deletes had to route around cfctl.

  • DNS record delete — the lifecycle is now governed create → update → patch → delete, with deletion verified by a not-found readback. Blocked previously because Cloudflare's OpenAPI under-declares the delete response envelope; cfctl pins it to the observed live shape (#91).
  • Queue consumer create and update — the delete side was already governed; both directions now are, accepting the worker and http_pull variants with returned-id verification and reviewed-delete compensation (#92).
  • Worker script delete — governed with a new verification strategy that reads the script's /settings sub-path for a 404 (the script's own GET returns the raw module body). cfctl never passes Cloudflare's force bypass, so in-use refusals (queue consumers, Durable Objects) stay active as a second guard (#93).
  • Access application create — governed with curated verification over name and type, the fields present across all 13 polymorphic application types. Access update stays blocked by design: the union has no honest universal field to verify against (#94).

Documented, still blocked

Three capabilities were investigated and left honestly blocked, each with its root cause recorded in the operator runbook's Known Limitations:

  • Access application create is governed in the catalog but currently fails at plan storage, because the redaction guard matches secret field names that appear as legitimate config keys in its large schema (#95).
  • KV namespace delete stays blocked: an empty-namespace emptiness proof would bound its cost, but that requires overriding the fail-closed cost block on a destructive op — deferred to its own reviewed change (#96).
  • Token update stays reserved to the governed keys workflow by doctrine, not promoted as a generic capability (#97).

Verification

cargo xtask verify exit 0. Each shipped capability was live-proven end to end against a real account with full cleanup: DNS create→delete, a complete queue-consumer lifecycle, and a Worker deploy→governed-delete cycle.