feat(policies): allow gate=false to override org-wide blocking

[matiasinsaurralde]

PR for #2769

This change implements per-policy gate override behavior for policy enforcement.

• Makes contract gate presence-aware so unset and explicit false are distinct.
• Adds effective gate resolution in policy evaluation:
  • unset gate inherits organization default strategy
  • gate: true enforces blocking for that policy
  • gate: false forces non-blocking for that policy
• Updates attestation push enforcement to rely on effective gated violations, with a safe fallback when policy evaluations are unavailable.
• Adds test coverage for gate inheritance and explicit override behavior.

[matiasinsaurralde]

buf:breaking:ignore per-field comment annotations do not exist in buf (only buf:lint:ignore do). To suppress the FIELD_SAME_CARDINALITY violation introduced by changing bool gate to optional bool gate, the exception was added to buf.yaml for the app/controlplane/api module.

Additionally, --exclude-imports was added to the buf breaking CI step to prevent crafting_schema.proto from being re-evaluated as an import in other modules (e.g. pkg/attestation/crafter/api), which would trigger the same violation a second time outside the module where the exception is defined.

Both the buf.yaml exception and the --exclude-imports flag can be removed once this change lands in main, since the baseline will no longer include the old field cardinality.

In order to try the buf breaking locally you can do (where b46ef29 is latest main):

buf breaking --against "https://github.com/chainloop-dev/chainloop.git#format=git,commit=b46ef29bb9c471b401a1dd083fcaad95fe72f021" --exclude-imports

[cubic-dev-ai]

No issues found across 12 files

[migmartri]

I am not sure we want to disable this globally but instead you coudl add an annotation in your specific case?

[matiasinsaurralde]

Note that breaking change detection doesn't support inline comment ignores.

• buf:lint references in Buf code.
• buf:breaking references in Buf code (no occurrences).

Also exceptions are only per file/directory level.

Given that we control the gRPC clients/servers that use these messages and that the bool to optional bool doesn't imply a wire format change in PB, it should be safe to regenerate the bindings and update any other parts of the code that use this message.

Also buf breaking always compares to latest main. If this PR lands (with or without the exceptions, which we can also leave out), a subsequent PR won't raise a breaking change error - cc @jiparis

[jiparis]

Yeah, unfortunately buf breaking doesn't support inline ignores as buf lint does. To be honest, I'm wondering how this is the first time we are facing this issue. Did we update buf recently?
The only solution is adding this top level except option. The change to optional is safe, as it only affects to generated code. Wired bytes are exactly the same (although with different semantics from now on).

[migmartri]

great, ptal at my comments, thanks

[migmartri]

I don't understand this change, mind elaborating a bit?

[matiasinsaurralde]

This was dead code from backwards compatibility code (that we don't need for this case), I've added comments about it on the cubic thread in this same PR.

[migmartri]

ok, so before the default gate was outside the context of policy verifier and now you are bringing both in?

[matiasinsaurralde]

Right, PolicyEvaluation.Gate was populated with the raw attachment value (attachment.GetGate()), while the org-level default (block_on_policy_violation) was applied later in CLI enforcement.

The efective gate is now resolved inside PolicyVerifier (policyAttachmentGate(attachment, pv.defaultGate)), following the 3 state behavior (to achieve default on / opt-out per policy):

• Explicit gate: true: blocking.
• Explicit gate: false: non-blocking (opt-out)
• Unset gate: inherits org default.

[cubic-dev-ai]

1 issue found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="app/cli/cmd/attestation_push.go">

<violation number="1" location="app/cli/cmd/attestation_push.go:199">
P1: Backward-compatible fallback removed: when `MustBlockOnPolicyViolations` is true but no policy evaluations are available (e.g., older server version or edge case), the function no longer blocks on `HasPolicyViolations`. This silently allows attestation pushes through despite policy violations. The PR description mentions "a safe fallback when policy evaluations are unavailable," but the fallback was actually deleted.

The remaining `if` block is also effectively a no-op for control flow — both branches return `nil` — so nothing blocks in the `MustBlockOnPolicyViolations` path anymore.

Consider restoring the fallback for the zero-evaluations case.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}