[finding] The environment artifact's `checksum` digests the `metadata` block only — the new `grantedPermissions` consent set (#14865) rides the envelope outside any integrity coverage

[zhuangjianguo]

Filed by the domain:spec seat (session session_0174WZTU6XcFcS7g2kykC53i, seat post #6017) from the contract review of PR #14992 (#14865), where the dev raised it as an observation with no change proposed. Observation for triage — not pm:queue; whether the granted set needs integrity coverage is a decision, not a mechanical fix, and it touches the security boundary (human floor for any change).

What is measured

• packages/spec/src/system/environment-artifact.zod.ts (file header, origin/main 44ffa210): the envelope's checksum (Sha256DigestSchema, line 104) is documented as covering the metadata block only — "Deployment Config … NOT in this schema"; the compiled metadata is what the digest identifies alongside commitId.
• PR feat(spec): declare grantedPermissions on EnvironmentArtifactSchema — install-time granted set per plugin manifest id (#14865) #14992 declares grantedPermissions: z.record(z.string(), PluginPermissionsSchema).optional() as a top-level envelope key beside metadata — exactly as ruled (manifest.permissions is live on its LEGACY string[] arm only — the structured PluginPermissionsSchema (services / hooks / network / fs) has zero readers, and new code is told to prefer it #11333 option A, Phase 1 of #11333: wire granted_permissions into PluginPermissionEnforcer (F4) as the load-time gate #13457 batch) and as filed on spec: declare grantedPermissions on EnvironmentArtifactSchema (record of manifest id → PluginPermissions) — the artifact-contract half of #14034 / #11333 Phase 1, which must land BEFORE cloud can write it (plain z.object strips undeclared keys at the artifact door) #14865. The docblock states it plainly: "Sits beside metadata, outside the checksum digest (which covers the metadata block only)."
• So the consented four-class permission set { services, hooks, network, fs } — the value the materialize-time loader hands to PluginPermissionEnforcer.registerGrantedPermissions — is control-plane state re-emitted per assembly and is NOT under the envelope's integrity digest. A carrier that altered that block would not fail the checksum.

Why it is a card and not a rider

The ruling placed the granted set on the artifact contract; it did not specify integrity coverage, and the envelope's digest was designed around compiled metadata. Extending the digest (or adding a second digest over the consent block) changes what the control plane signs and what the runtime verifies — a contract change on a security boundary, which is the maintainer's decision. The neighbouring cards are different gaps: #11331 / #13563 are manifest.integrity per-file digests of the .osplugin package, not the envelope's consent block.

Questions for the decision (when triage grades it)

1. Does the consent set need integrity coverage at all, given the artifact is served by the control plane over the environment-local carrier (ADR-0003 / cloud ADR-0007)? If the carrier is trusted end to end, the answer may be "documented, no change".
2. If yes: widen checksum to cover metadata + grantedPermissions (a breaking change to what checksum means — every producer and verifier moves), or add a sibling digest for the consent block (additive, verifier opt-in).

Dedupe: search_issues "environment artifact checksum digest covers metadata only grantedPermissions consent state outside integrity" → nearest #11331 (manifest.integrity per-file digests) and #13563 (its cloud enforce leg); neither is this gap.