[dependabot]

Bumps github.com/open-policy-agent/opa from 1.3.0 to 1.21.4.

Release notes

Sourced from github.com/open-policy-agent/opa's releases.

v1.21.4

This release builds the OPA binary artifacts with the latest version of Go (v1.27.3).

See: https://groups.google.com/g/golang-announce/c/66pojueaQek

v1.21.3

Bundle signature verification could be side-stepped (GHSA-g2pf-6v5v-qcc8)

An attacker able to alter bundle bytes could supply arbitrary policy and data to an OPA that was configured to verify bundle signatures. This could happen if the attacker controls any of:

• OPA bundle/discovery service (including an artifact store it uses)
• MitM between OPA and bundle/discovery service
• write access to a file:// bundle path or the bundle persistence directory

Two separate side-steps are fixed:

Issue 1. Signature verification keyed on keyid rather than on the signing block

OPA only required a .signatures.json file when signing.keyid was set, so a bundle stripped of its signature was accepted if only e.g. bundles[_].signing was set instead of bundles[_].signing.keyid. Verification now depends on the presence of a signing block, as documented; keyid only selects which key to use.

Affected:

• bundles[_].signing or discovery.signing configured without keyid: an empty block, or one with only scope or exclude_files.
• Embedders (SDK, custom plugins, v1/loader, v1/compile) calling bundle.NewVerificationConfig(keys, "", ...) with an empty key id.

Not affected:

• Configurations with an explicit bundles[_].signing.keyid or discovery.signing.keyid.
• opa run/opa eval/opa build with --verification-key, which defaults --verification-key-id to default. Passing --verification-key-id "" explicitly was affected.
• Configurations with top-level keys but no signing block: not a verification opt-in before or after this fix. Unsigned bundles are still accepted, and OPA now logs a warning at startup for bundles in this state.

Workaround: on affected versions, set an explicit keyid on every bundle that must be signed:

bundles:
  authz:
    service: acmecorp
    resource: bundle.tar.gz
    signing:
      keyid: my_key # must name an entry under the top-level `keys`
</tr></table> 

... (truncated)

Changelog

Sourced from github.com/open-policy-agent/opa's changelog.

1.21.4

This release builds the OPA binary artifacts with the latest version of Go (v1.27.3).

See: https://groups.google.com/g/golang-announce/c/66pojueaQek

1.21.3

Security Fix: Bundle signature verification could be side-stepped (GHSA-g2pf-6v5v-qcc8)

An attacker able to alter bundle bytes could supply arbitrary policy and data to an OPA that was configured to verify bundle signatures. This could happen if the attacker controls any of:

• OPA bundle/discovery service (including an artifact store it uses)
• MitM between OPA and bundle/discovery service
• write access to a file:// bundle path or the bundle persistence directory

Two separate side-steps are fixed:

Issue 1. Signature verification keyed on keyid rather than on the signing block

OPA only required a .signatures.json file when signing.keyid was set, so a bundle stripped of its signature was accepted if only e.g. bundles[_].signing was set instead of bundles[_].signing.keyid. Verification now depends on the presence of a signing block, as documented; keyid only selects which key to use.

Affected:

• bundles[_].signing or discovery.signing configured without keyid: an empty block, or one with only scope or exclude_files.
• Embedders (SDK, custom plugins, v1/loader, v1/compile) calling bundle.NewVerificationConfig(keys, "", ...) with an empty key id.

Not affected:

• Configurations with an explicit bundles[_].signing.keyid or discovery.signing.keyid.
• opa run/opa eval/opa build with --verification-key, which defaults --verification-key-id to default. Passing --verification-key-id "" explicitly was affected.
• Configurations with top-level keys but no signing block: not a verification opt-in before or after this fix. Unsigned bundles are still accepted, and OPA now logs a warning at startup for bundles in this state.

Workaround: on affected versions, set an explicit keyid on every bundle that must be signed:

bundles:
  authz:
    service: acmecorp
    resource: bundle.tar.gz
    signing:
      keyid: my_key # must name an entry under the top-level `keys`
discovery:
</tr></table> 

... (truncated)

Commits

• 05c8451 Release 1.21.4
• bbfea76 build: bump go (1.27.2 -> 1.27.3) (#9421)
• ba9214e changelog: link the bundle signature verification advisory (#9405)
• fa9da82 Release 1.21.3 (#9403)
• c9d71bf bundle: Reject unsigned bundles when signature verification is configured wit...
• 3f7474e Release 1.21.2
• a48c42a server: resolve encoded request paths consistently in authorizer and handlers...
• 60edfb2 build: bump go (1.27.1 -> 1.27.2) (#9340)
• 2a109e5 Prepare v1.21.1 release
• 9057ccb ast: treat SomeDecl/Every exprs as non-ground in Expr.IsGround
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)