Open Policy Agent: baixar versions anteriors

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](https://groups.google.com/g/golang-announce/c/66pojueaQek)

v1.21.3

### Bundle signature verification could be side-stepped (https://github.com/open-policy-agent/opa/security/advisories/GHSA-g2pf-6v5v-qcc8)

An attacker able to alter bundle bytes could supply arbitrary policy and data to an OPA that was [configured](https://www.openpolicyagent.org/docs/configuration#bundles)
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:

```yaml
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:
algorithm：RS256
key：|
-----BEGIN PUBLIC KEY-----
...
```

Further behaviour changes:

• A `signing` block with no entries under the top-level `keys` is now a startup configuration error, rather than a
configuration that rejects every signed bundle while accepting unsigned ones.
• `bundle.NewVerificationConfig` now requires signatures by default. Embedders can opt out with
`WithSkipBundleVerification(true)` or the new `(*VerificationConfig).WithOptionalSignature()`.

#### Issue 2. Unsigned _delta_ bundle downgrade

_Delta_ bundles skipped verification entirely, so an attacker could replace a signed _snapshot_ bundle with an unsigned
_delta_ bundle on the same resource. The signed policy stays active while the attacker controls any data inside the
bundle's roots. _Delta_ bundles [not supporting signing](https://www.openpolicyagent.org/docs/management-bundles#current-limitations)
was documented, but unenforced. OPA now rejects them with `delta bundles do not support signature verification`.

**Affected:**

• Any bundle or discovery configuration with a `signing` block, with or without `keyid`.
• `opa run`/`opa eval` with `--verification-key`.

**Not affected:**

• Configurations that don't verify signatures：no `signing` block, or `--skip-verify`. Nothing was verified to begin
with.

**Workaround:** there is no configuration that makes affected versions reject _delta_ bundles. Until upgrading, ensure
the integrity of the bundle bytes themselves：TLS terminated by OPA or a trusted hop, restricted write access to the
bundle service, artifact store and bundle persistence directory.

Bundle services that must keep serving unsigned _delta_ bundles after upgrading can opt out per bundle with the new
`bundles[_].signing.allow_unsigned_delta_bundles` (or `discovery.signing.allow_unsigned_delta_bundles`) field.
_Snapshot_ bundles 

This release builds the OPA binary artifacts with the latest version of Go (v1.27.2), its standard library, and the golang.org/x/net dependency (v0.60.0).

See these security advisories:
• https://groups.google.com/g/golang-announce/c/U2fTuyDJznI
• https://groups.google.com/g/golang-announce/c/ZPwCyRUuGBs

Furthermore, it addresses a mismatch in how encoded slashes were handled in the input to a basic authorization policy and the Data API (#9323, reported by @abhishekkushwaha4u, fixed by @sspaink).

This release fixes a compiler regression introduced in OPA v1.21.0.

### Fix `some … in`/`every` in comprehensions nested in object and set literals ([#9280](https://github.com/open-policy-agent/opa/issues/9280))

A comprehension using `some … in` or `every` in its body, nested inside an object or set literal, was wrongly treated as ground, so the compiler skipped rewriting it. `some … in` then failed with `rego_unsafe_var_error`; `every` caused a compiler panic:

```rego
package example

p := {"k"：[r.a | some r in input.xs]} # rego_unsafe_var_error: var r is unsafe

q := {[1 | every x in input.xs { x > 0 }]} # panic
```

Array literals weren't affected, and neither were literals that contain some other non-ground term.

authored by @srenatus, reported by @tun0

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

• Improved rule indexing
• Improved rule recursion check
• YAML is parsed against the 1.2 core schema (breaking change)

### Rules with general refs no longer collide in the recursion check ([#6813](https://github.com/open-policy-agent/opa/issues/6813))

Before, this was a recursion error:

```rego
package play

p[x].foo.bar if {
x := "a"
not p[x].foo.baz
}

p[x].foo.baz if {
x := "a"
false
}
```

Rules with a variable in their head are all stored at the ground prefix of their ref, so
`p[x].foo.bar` and `p[x].foo.baz` looked like dependencies of each other. The compiler is
now less conservative and compares the ref parts past the prefix. Genuine cycles are still
reported.

The IR and Wasm targets however still return an error：they plan one function per ground
path prefix, and cannot evaluate part of a function that is still being planned.

Authored by @sspaink, reported by @tsandall

### Data and Query APIs can return rule labels in the response ([#9211](https://github.com/open-policy-agent/opa/pull/9211))

`# METADATA` `labels` for evaluated rules were only available in decision log
events. The Data API (`GET`/`POST /v1/data`) and Query API (`GET`/`POST
/v1/query`) now accept a `rule_labels` query parameter to include the same
merged labels in the response payload, under a `rule_labels` key.

Authored by @srenatus

### Behavior change：response gzip compression now bounds its buffer to `min_length` ([#9205](https://github.com/open-policy-agent/opa/pull/9205))

The server's gzip response compression (`server.encoding.gzip`) buffered an entire
incoming `Write` call before deciding whether to compress, so a single large write could
grow the buffer well past `min_length` before that decision was made. The handler is now
built on [`klauspost/compress/gzhttp`](https://github.com/klauspost/compress/tree/master/gzhttp)
instead of a hand-rolled buffer and `gzip.Writer` pool, which caps what it buffers to
`min_length` (floored at 512 bytes) before streaming the remainder through the chosen
path. `min_length` and `compression_level` behave the same as before; only gzip is
negotiated, not zstd.

Authored by @srenatus

### YAML is now parsed against the 1.2 core schema ([#5754](https://github.com/open-policy-agent/opa/issues/5754), [#6598](https://github.com/open-policy-agent/opa/issues/6598))

OPA parsed YAML with a library pinned to go-yaml v2, which implements YAML 1.1. Under
1.1, the bare words `y`, `n`, `yes`, `no`, `on` and `off` resolve to booleans, so a
GitHub Actions workflow loaded with `--data` came back with `true` where it should have
had `on`:

```yaml
on：push
```

```json
{ "true"："push" }
```

These words are now plain strings, as the YAML 1.2 core schema specifies. `true` and
`false` are unaffected. This applies everywhere OPA reads YAML：`--data`, bundles,
config files, and the `yaml.unmarshal` builtin.

If you were relying on `yes`/`no`/`on`/`off` being read as booleans, quote the value and
use `true`/`false` instead.

Authored by @sspaink, reported by @scnewma and @johnc-c

### Empty composite literals are now typed as empty ([#7275](https://github.com/open-policy-agent/opa/issues/7275))

The type checker used to give the empty object literal `{}` the type
`object[any：any]`, the empty array literal `[]` the type `array[any]`, and the
empty set literal `set()` the type `set[any]`, i.e. the types of a collection
that may hold anything. Every other literal is typed by its contents, so
referencing a key that isn't there is caught at compile time — but only for
non-empty literals:

```rego
obj := {"foo"："bar"}
obj.bar # rego_type_error：undefined ref: obj.bar

obj := {}
obj.bar # compiles
```

Empty literals are now typed as what they are：an object with no properties, an
array with no items, and a set with no members. Both examples above now fail to
compile, and so does every other way of selecting from an empty literal,
including iterating one (`some x in []

v1.20.2

This release includes a bug fix for a parser regression introduced in v1.20.0, and dependency
updates.

### Fix stale parse errors on statements starting with `{` ([#9140](https://github.com/open-policy-agent/opa/pull/9140))

When the `and`/`or` keywords added in v1.20.0 are imported, a statement that starts with `{` is
first read as an explicit operand body, and re-read as a term (a comprehension, for example) if no
`and` or `or` follows. Errors recorded during the abandoned first attempt stayed in the parser's
term cache and were reported against the successful re-read, rejecting policies that parse fine:

```rego
package example

import future.keywords

xs := [1, 2, 3]

allow if {
{
y |
some y in xs # rego_parse_error：unexpected some keyword
} == {1, 2, 3}
}
```

The term cache is now restored along with the rest of the parser state when the operand-body guess
is abandoned. Only policies importing `and` or `or` — directly or via `import future.keywords` —
were affected; policies that don't import them parse unchanged.

Authored by @sspaink

### Miscellaneous

• build(go)：Bump to 1.27.1 ([`3652eeb`](https://github.com/open-policy-agent/opa/commit/3652eeb404c7d1aead99e831a1c418cfbd362784)) authored by @srenatus
• Dependency updates; notably:
• build(deps)：Bump github.com/dgraph-io/badger/v4 from 4.9.5 to 4.9.6
• build(deps)：Bump github.com/lestrrat-go/jwx/v3 from 3.1.1 to 3.2.0
• build(deps)：Bump github.com/santhosh-tekuri/jsonschema/v6 from 6.0.2 to 6.0.3
• build(deps)：Bump github.com/sirupsen/logrus from 1.9.4 to 1.10.2
• build(deps)：Bump go.opentelemetry.io/contrib/bridges/prometheus from 0.69.0 to 0.71.0
• build(deps)：Bump go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp from 0.69.0 to 0.71.0
• build(deps)：Bump go.opentelemetry.io/otel from 1.44.0 to 1.46.0
• build(deps)：Bump go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc from 1.44.0 to 1.46.0
• build(deps)：Bump go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp from 1.44.0 to 1.46.0
• build(deps)：Bump go.opentelemetry.io/otel/exporters/otlp/otlptrace from 1.44.0 to 1.46.0
• build(deps)：Bump go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc from 1.44.0 to 1.46.0
• build(deps)：Bump go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp from 1.44.0 to 1.46.0
• build(deps)：Bump go.opentelemetry.io/otel/sdk from 1.44.0 to 1.46.0
• build(deps)：Bump go.opentelemetry.io/otel/sdk/metric from 1.44.0 to 1.46.0
• build(deps)：Bump go.opentelemetry.io/otel/trace from 1.44.0 to 1.46.0
• build(deps)：Bump go.yaml.in/yaml/v3 from 3.0.4 to 3.0.5
• build(deps)：Bump golang.org/x/text from 0.40.0 to 0.41.0
• build(deps)：Bump google.golang.org/grpc from 1.82.1 to 1.83.2
• build(deps)：Bump google.golang.org/protobuf from 1.36.11 to 1.36.12

This release includes a bug fix for a regression introduced in v1.20.0 in
[comparing a number to some float values](https://github.com/open-policy-agent/opa/issues/9098).
Thanks @kmadan for reporting the issue and submitting a fix!

This release uses the latest version of Go (1.26.6) to build OPA, fixing stdlib vulnerabilities in code that OPA's HTTP handler and crypto builtins use:

• https://pkg.go.dev/vuln/GO-2026-6218
• https://pkg.go.dev/vuln/GO-2026-6091
• https://pkg.go.dev/vuln/GO-2026-6090
• https://pkg.go.dev/vuln/GO-2026-6089
• https://pkg.go.dev/vuln/GO-2026-6088
• https://pkg.go.dev/vuln/GO-2026-5972
• https://pkg.go.dev/vuln/GO-2026-5026

It is otherwise the same code as v1.19.0.

Note that users building their own OPA binaries and images already control the Golang version, so this is not relevant for them.

### Miscellaneous

• build(go)：bump to 1.26.6 (authored by @srenatus)