Open Policy Agent: descargar versiones anteriores

This is a bugfix release for a type checker regression in v1.21.0.

### Iterating an empty collection is rejected by the type checker

Policies that iterate a collection known to be empty, such as `some x in []` or `m[_]` where `m := {}`,
were rejected with `rego_type_error：undefined ref`. Iteration with a non-constant key is valid again, and simply
yields nothing. Comparing or unifying the elements of such a collection with a value is accepted as well.
Constant keys, like `[][0]`, are still reported as undefined.

Reported by @kholia.

v1.22.0

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

• New `rego.v2` import
• Configurable log level for HTTP access logs
• Stricter handling of bundle signature filenames (breaking change)
• Partial evaluation unrolls `every` over a known domain

### Configurable log level for HTTP access logs

Added `--log-level-request` (default `info`) to control the level at which the HTTP
server's "Received request."/"Sent response." access log lines are emitted, independent
of the general `--log-level`. Set it to `debug` to keep those lines out of logs unless
`--log-level` is also turned up.

Authored by @srenatus

### New `rego.v2` import ([#9224](https://github.com/open-policy-agent/opa/issues/9224), [#9269](https://github.com/open-policy-agent/opa/issues/9269))

`import rego.v2` enables the `and` and `or` keywords and the improved `not` semantics in one
import, in place of `future.keywords.and`, `future.keywords.or`, and `future.keywords.not`.
In a v0 module it also implies `rego.v1`. It is gated by the new `rego_v2_import` capability
feature.

```rego
package example

import rego.v2

allow if input.user.admin or not (input.user.suspended or input.user.locked)
```

See [Importing `rego.v2`](https://www.openpolicyagent.org/docs/policy-reference/keywords/import#importing-regov2).

Additionally：bundles can be declared as Rego v2 by setting the `rego_version` manifest attribute to `2` (individua
bundle modules by setting `file_rego_versions`); and the Go API accepts the new `ast.RegoV2` rego-version when parsing,
compiling, and formatting Rego modules.
The `rego.v2` import is a redundant no-op for modules loaded these ways.

See [bundle file format](https://www.openpolicyagent.org/docs/management-bundles#bundle-file-format).

Authored by @johanfylling

### Stricter handling of bundle signature filenames ([#9300](https://github.com/open-policy-agent/opa/pull/9300))

Breaking change：We have corrected a long-standing bug in bundle signing and verification, which will cause bundles containing files matching the suffix pattern `*signatures.json` to no longer pass verification in newer versions of OPA.
These bundles will need to be re-signed by this or newer versions of OPA to have a correct `.signatures.json` file.
Bundles that do not contain filenames with the `*signatures.json` pattern are unaffected, and will continue to verify correctly across OPA versions.

OPA has historically been very lax in deciding where to source bundle signature data from during bundle verification, and would attempt to load bundle signatures data from *any* file in the bundle that had the filename suffix pattern `*signatures.json`.

This could cause surprising behavior at bundle verification time, and resulted in all files with the `*signatures.json` pattern being ignored for signing, allowing filenames like `foosignatures.json` to be added to a bundle without being integrity-checked by the bundle signature.

OPA now identifies the bundle signatures file by its exact basename `.signatures.json` (the same way it locates the bundle manifest and data files), so it is found regardless of any directory prefix, and a bundle containing more than one signatures file is rejected.
Additionally, OPA will now correctly detect and sign all other files with the suffix pattern `*signatures.json`, which may cause bundles signed by this and future versions of OPA to have different signatures from the same content signed by older versions of OPA.

Authored by @philipaconrad

### Partial evaluation unrolls `every` over a known domain

Partial evaluation now evaluates an `every` over a known collection of at most 32 elements (counting nested `every`s together) once per element, instead of keeping it in the result when its body has unknowns. The result is the conjunction of the body for each element, which the data filtering targets of the Compile API can translate. See [`every`](https://www.openpolicyagent.org/docs/policy-reference/

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)