CheeseSec Plugin Handbook

This handbook includes contracts and planned capabilities. Examples do not authorize plugin installation. Capability status remains as described in each page and its acceptance evidence.

Store and OTA Contract (v1, contract-only)

This handbook defines the CheeseSec catalog, OTA, resource endpoints, and plugin runtime boundary. It is an auditable publication contract, not a claim that online services or an installer are deployed. Machine-readable schemas live in CheeseSec_Plugin/schema/store-v1/ and are mirrored under https://store.cheesesec.com/schema/store/v1/. The Pages, Worker, R2, and server split is defined in the Cloudflare edge routing contract.

Three fixed endpoints

EndpointRoleMethodsKey constraint
https://store.cheesesec.comcatalogGET, HEADpublishes reviewed release summaries only
https://ota.cheesesec.comversion indexGET, HEADpull-only, monotonically increasing index sequence
https://res.cheesesec.comimmutable resourceGET, HEADURL is bound to a SHA-256 content address; redirects denied

Endpoints accept no plugin credentials. Online pulls require administrator password confirmation, a one-shot Socket Lease, and audit. Offline mode must make zero network requests.

Edge and server split

Catalog, policy, schema, OTA indexes, and content-addressed resources are public read surfaces. The Worker accepts only GET and HEAD and reads R2 through fixed paths. An unknown Host returns 421; an unknown path returns 404; neither is forwarded to the server.

Console, management APIs, authentication, setup, approvals, CRP activation, CWEDP, diagnostic uploads, SSE, and WebSocket traffic stay on the server. The Worker may proxy only to the configured ORIGIN_BASE_URL and adds the Cloudflare Access identity and Origin HMAC. The server still performs Session, CSRF, RBAC, and audit checks, and admin_listen remains on loopback.

The complete object-key, cache, header, and release checklist is in the Cloudflare edge routing contract and its Chinese version.

The publication repository uses scripts/build_publication_bundle.py to create a deterministic R2 bundle. The builder runs the contract checks first and copies only JSON publication objects plus a digest manifest. It does not read signing private keys or create CRP archives. scripts/publish_r2.sh prints a publication plan by default; only an explicit --apply writes to R2. The script checks the current catalog pointer sequence and uploads versioned objects before public objects and pointers.

Trust levels

The six supported namespaces are official, enterprise, community, personal, test, and development. Trust level describes provenance and never grants runtime capability; capability is still controlled by the sidecar descriptor, resource limits, approval, and policy.

  • Official and certified enterprise normal releases use 2-of-3 signatures; high-risk releases use 3-of-5. An enterprise root is restricted to enterprise/<org>/<plugin>.
  • Community, personal, test, and development releases require administrator confirmation by default; maximum key lifetimes are 365, 365, 30, and 7 days.
  • Official and enterprise keys have a maximum lifetime of 1095 days. Rotation and revocation retain old records and never overwrite publication history.

Immutable release and withdrawal

Each release binds namespace@version#release_sequence, all three CRP digests, manifest/signature-set/descriptor/provenance digests, source root, review evidence, and the signature verification report. Published records are append-only: they cannot be rewritten, downgraded, or changed by a mirror. Withdrawal is an appended event with a reason and evidence digest; an OTA index must stop referencing a withdrawn release.

Offline import

Offline import requires a local .crp, trust roots, a source registry, and a revocation snapshot. The order is: exact CRP three-entry layout, manifest/schema, artifact size plus MD5/SHA-1/SHA-256, source-root binding, signature threshold and validity, revocation and release sequence, then administrator confirmation where required. Any failure rejects installation and activation. Only a package that clears every gate can enter the CheeseWAF staged flow. An expired revocation snapshot keeps last-known-good running while blocking new installation, upgrade, and promotion.

34A sidecar and CWEDP

Plugins run as asynchronous sidecars. The first mode is observe, default egress=deny, and the allowed outputs are snapshots, hints, and health state; request handling never waits for plugin I/O. WASM and in-process native plugins are outside this contract.

A notifier provider pack is a separate contract (crp.cheesewaf.io/notifier/v1). It is not a sidecar capability and never enters the CWEDP install flow. It only describes a delivery target for the core notifier; sidecar egress stays fixed to deny, and the core owns egress, credentials, and audit. See the Notifier Provider Pack Contract.

CWEDP is the only executor for installation, upgrade, rollback, and cluster distribution. After HELLO/CAPABILITIES/DistributionIntent negotiation, a node may pull from OTA, an authorized seed, an authorized peer, or an offline CRP. Ansible only bootstraps the distribution agent; it cannot push or replace CRP. Transfers retain all three digests, a signed manifest, content-addressed chunks, and source independence/quarantine records.

These pages and fields are contract examples. Until CheeseWAF stage evidence exists, store, OTA, CWEDP, and plugin activation must not be described as live capabilities.