[dependabot]

Bumps github.com/open-policy-agent/opa from 1.21.1 to 1.21.3.

Release notes

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

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`
discovery:
  resource: /discovery.tar.gz
  signing:
    keyid: my_discovery_key
keys:
</tr></table>

... (truncated)

Changelog

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

1.21.3

Security Fix: TODO-CVE-XXXX-XXXXX - 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:
  resource: /discovery.tar.gz
  signing:
    keyid: my_discovery_key
keys:
my_key:
</tr></table>

... (truncated)

Commits

• 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)
• See full diff 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)

[dependabot]

Labels

The following labels could not be found: dependencies, go. Please create them before Dependabot can add them to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.