Bump github.com/open-policy-agent/opa from 1.18.2 to 1.19.0

[dependabot]

Bumps github.com/open-policy-agent/opa from 1.18.2 to 1.19.0.

Release notes

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

v1.19.0

This release contains a mix of new features and bug fixes. Notably:

• A fixed SQL injection vector in the Compile API
• Stricter safety checking for Rego assignments (:=)
• A cgo-free, faster WebAssembly runtime (wazero replaces wasmtime-go)
• Startup warnings for unknown configuration options
• A new strings.split_n built-in function
• A REPL line reader that handles pasted input correctly, migrating existing history files

Fix SQL injection vector in Compile API: Quote SQL filter field identifiers (#8945)

The field names in the SQL emitted by the Compile API come from partially evaluated refs, so a policy that selects a dynamic key — such as input.fruits[input.column] — puts caller-controlled text in an identifier position. That text was emitted verbatim, which turns

WHERE fruit.name = 'allowed'

into

WHERE fruit.name = 'allowed' OR 1=1 -- = 'allowed'

and an application appending the filter to its query returns rows the policy denies.

Field segments that are not bare identifiers are now quoted at the UCAST-to-SQL boundary, with any embedded quote character escaped. Ordinary column names stay unquoted, so existing filters keep their current shape and remain case-insensitive on Postgres.

Authored by @​thevilledev

Behavior change: stricter safety for assignment (:=) (#3546)

The assignment operator (:=) is documented as "syntactic sugar for =, local variable creation, and additional compiler checks," and the safety checker reflects that: after rewriting, := is treated identically to = (unification), so an assignment's right-hand side can be made safe by unifying "backwards" through the left-hand side. This means policies like x := y; x = 7 compile (binding y to 7) even though y is never assigned, and x := y; obj[x] can silently degrade an expected constant-time lookup into full iteration.

This change makes the right-hand-side of := be treated as a read that must be made safe by other expressions, and can no longer be satisfied through the left-hand-side. Affected policies that previously compiled now fail with a rego_unsafe_var_error. Reference iteration on the right-hand-side (e.g. some k; v := obj[k]) is unaffected.

... (truncated)

Changelog

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

1.19.0

This release contains a mix of new features and bug fixes. Notably:

• A fixed SQL injection vector in the Compile API
• Stricter safety checking for Rego assignments (:=)
• A cgo-free, faster WebAssembly runtime (wazero replaces wasmtime-go)
• Startup warnings for unknown configuration options
• A new strings.split_n built-in function
• A REPL line reader that handles pasted input correctly, migrating existing history files

Fix SQL injection vector in Compile API: Quote SQL filter field identifiers (#8945)

The field names in the SQL emitted by the Compile API come from partially evaluated refs, so a policy that selects a dynamic key — such as input.fruits[input.column] — puts caller-controlled text in an identifier position. That text was emitted verbatim, which turns

WHERE fruit.name = 'allowed'

into

WHERE fruit.name = 'allowed' OR 1=1 -- = 'allowed'

and an application appending the filter to its query returns rows the policy denies.

Field segments that are not bare identifiers are now quoted at the UCAST-to-SQL boundary, with any embedded quote character escaped. Ordinary column names stay unquoted, so existing filters keep their current shape and remain case-insensitive on Postgres.

Authored by @​thevilledev

Behavior change: stricter safety for assignment (:=) (#3546)

The assignment operator (:=) is documented as "syntactic sugar for =, local variable creation, and additional compiler checks," and the safety checker reflects that: after rewriting, := is treated identically to = (unification), so an assignment's right-hand side can be made safe by unifying "backwards" through the left-hand side. This means policies like x := y; x = 7 compile (binding y to 7) even though y is never assigned, and x := y; obj[x] can silently degrade an expected constant-time lookup into full iteration.

This change makes the right-hand-side of := be treated as a read that must be made safe by other expressions, and can no longer be satisfied through the left-hand-side. Affected policies that previously compiled now fail with a rego_unsafe_var_error. Reference iteration on the right-hand-side (e.g. some k; v := obj[k]) is unaffected.

... (truncated)

Commits

• 1e32c79 Prepare v1.19.0 release (#8955)
• db035b0 Add support for Go 1.27 & jsonv2 (#8947)
• 27fe5ce ast: Fix leaky future.keywords.not import in Rego v0 (#8953)
• ab21870 format: Keep rule body inline when the head spans multiple lines (#8904)
• 95090fa Add strings.split_n built-in function (#8915)
• 12a86ed build(deps): bump find-my-way and prisma in /e2e/api/compile/prisma
• 18815e2 build(deps): bump the dependencies group across 2 directories with 5 updates
• f1e2ac0 build(deps): bump postcss from 8.5.15 to 8.5.23 in /docs
• d9c7856 build(deps): bump js-yaml from 5.2.1 to 5.2.2 in /docs
• 69d2cc0 tester: make Result JSON round-trippable (#8946)
• Additional commits viewable in compare view