build(deps): 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

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

🟢 Coverage ∅ diff coverage · 0.00% coverage variation

Metric	Results
Coverage variation	✅ 0.00% coverage variation (-1.00%)
Diff coverage	✅ ∅ diff coverage

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (9df3881)	83927	19257	22.94%
Head commit (2bb3e8f)	83927 (+0)	19255 (-2)	22.94% (0.00%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#3231)	0	0	∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}