Some are runtime generated in the report and so are false positives. But
there are still others that need to be addressed, this is just the easy
ones.
Signed-off-by: Charlie Egan <charlie_egan@apple.com>
This was overly specific before, and quickly failed when fail events had
not been on of the right sort. Now, we're more lenient.
These would happen, as in https://github.com/orgs/open-policy-agent/discussions/722#discussioncomment-14812737,
when a fail event happened that's unrelated to unknowns lookup, but a
valid failure nonetheless. So this will not lead to a hint. Only fail
events of the previously-expected form could yield hints.
Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
This was previously done in several places in a somewhat convoluted way,
which probably made sense at some point. As expected however, a few small
local variations had emerged, and while nothing critical, this code wasn't
very nice to work with.
Some comments stated as the rationale for the design was avoiding allocations,
but those were nowhere to be seen when measured now, meaning there was no good
reason to have it remain this way! It was *quite* nice to be able to merge
the numbers comparsion functions (in particular) together into one!
We now have a unified way for comparing Number values throughout the AST package,
and as an added bonus, `1.0 == 1` is now true consistently for Rego.
See for example @srenatus example in https://github.com/open-policy-agent/opa/issues/4797
```
$ opa eval -fpretty 'count({1.0, 1})'
2
```
Doing the same now gives:
```
$ go run main.go eval -fpretty 'count({1.0, 1})'
1
$ go run main.go eval -fpretty 'count({1.0, 1, 1.000, 1.00000})'
1
```
What I have left out for now is however _presentation_. Meaning that
even though 1.0 and 1 is now treated as the same value, you may still
see either '1' or 1.0' (or whatever) displayed, depending on what was
parsed. Should be easy to fix, but could perhaps be perceived as
surprising... so holding off on that until we've had a discussion on
the topic.
Signed-off-by: Anders Eknert <anders@eknert.com>
Due the way that wasmtime-go does its versioning, it seems to fly under
the radar of dependabot: that will never propose major version bumps, I
suppose.
Signed-off-by: Stephan Renatus <stephan@styra.com>
While the static binaries will not go away, let's steer people towards
the binaries with less confusing names, now that we (are going to) have
them.
Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
Previously, we excluded this because github had no arm64 runners,
and our maintainers had no access to arm64 machines. These days,
both is no longer a problem.
If we do this, you can finally pull openpolicyagent/opa:latest on
macos/arm64 without a platform warning (and emulation). Before,
you had to resort to using :latest-static, which is somewhat non-
intuitive.
Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
We should invest some time in understanding how to better utilize this in
OPA. But for the time being, this at least allows clients like Regal to avoid
allocating for lookups when terms in the path are already interned by them.
Also added the string "10" to the set of interned strings, as I found that was
missing :) And a cosmetic fix in the parser code.
Benchmarks found in the code.
Signed-off-by: Anders Eknert <anders@eknert.com>
Before, we'd see these benchmarks die with
benchmark.go:412: B.Loop called with timer stopped
Now, we can run them again:
```
% go test -bench=. -v -run=XXX ./v1/test/e2e/authz
{
"level": "info",
"msg": "Test server ready and listening on: http://127.0.0.1:64200",
"time": "2025-10-15T11:44:06+02:00"
}
goos: darwin
goarch: arm64
pkg: github.com/open-policy-agent/opa/v1/test/e2e/authz
cpu: Apple M4 Max
BenchmarkRESTAuthzForbidAuthn
BenchmarkRESTAuthzForbidAuthn-16 22623 52375 ns/op
BenchmarkRESTAuthzForbidPath
BenchmarkRESTAuthzForbidPath-16 16729 71916 ns/op
BenchmarkRESTAuthzForbidMethod
BenchmarkRESTAuthzForbidMethod-16 16434 72963 ns/op
BenchmarkRESTAuthzAllow10Paths
BenchmarkRESTAuthzAllow10Paths-16 15883 74936 ns/op
BenchmarkRESTAuthzAllow100Paths
BenchmarkRESTAuthzAllow100Paths-16 10000 109283 ns/op
BenchmarkRESTAuthzAllow1000Paths
BenchmarkRESTAuthzAllow1000Paths-16 2731 462167 ns/op
PASS
ok github.com/open-policy-agent/opa/v1/test/e2e/authz 13.349s
```
Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
Treat generated variables as safe during rewritePrintCalls's safety
analysis stage. This prevents an "undeclared" error originating from
from head keys within inner comprehensions. These head keys would
typically be marked safe in later compiler stages. A "proper" safety
analysis would require further compiler context and comprehension
rewriting. Instead this fix avoids duplicating the logic of later
compiler stages.
Fixes: #7647
Signed-off-by: David Schmitt <davidschmittgit@gmail.com>
Have done this some time in the past, but there was a few
new issues this would highlight now that we're on Go 1.24.
Mostly:
- Use `b.Loop()` in benchmarks
- Use `strings.SplitSeq` where possible
- Remove `omitempty` tag for types that can't be empty
Signed-off-by: Anders Eknert <anders@eknert.com>
This is only needed for the built-in function context, so can be
initialzied the first time those are called. This has no impact on
real-world performance in any way, but is only meant to further
improve the `opa bench 1` "issue" — which is that users running
`opa bench` always see a "baseline" number of allocs (and more)
that have nothing to do with the code they benchmark but comes
from plumbing together the evaluator.
This baseline number was 53 allocs/op when I started on this side
quest, and this commit brings it down to 33 🙂
Signed-off-by: Anders Eknert <anders@eknert.com>
- Use new `util.SlicePool` to avoid cost of temporary slices in `formatTerm`
- Add `SkipDefensiveCopying` option and enable it for all `Source`* functions
```
676179 ns/op 995204 B/op 8850 allocs/op // regression in 0fb7526
513570 ns/op 378787 B/op 8775 allocs/op // addressed regression with sync.Pool
481681 ns/op 352130 B/op 7954 allocs/op // new util.NewSlicePool using only pointers
365116 ns/op 160528 B/op 2098 allocs/op // new SkipDefensiveCopying option
```
Signed-off-by: Anders Eknert <anders@eknert.com>
The way the gzip reader was returned to the sync.Pool meant
there were cases where it could either be nil, or not returned
to the pool.
Also simplified the function a bit.
Signed-off-by: Anders Eknert <anders@eknert.com>
I was meant to do slides for a talk, but here we are.
Fun exercise in "writing" a string without actually writing
one, but rather by trying to exclude all other possible
built-in function names to compare against ref as early as
possible in order to make the operation inexpensive. And it
worked! Down from a few allocations (worst case) and at least
3 digit ns/op, to no allocations and lower end of the 2 digit
ns/op scale.
For reference, this PR accounts for 700K allocations gone
in `regal lint bunde`, as we do millions of builtin function
calls as part of that benchmark.
Another 300K+ allocs gone by revisiting the `canSkipBctx`
field on the AST builtin struct, and making it public sp that
client like Regal may benefit. And we did :)
Signed-off-by: Anders Eknert <anders@eknert.com>
* Adds ecosystem project Moat
Moat is an OPA control plane project specifically for managing access to data. The
first target system is Trino, with many future target systems including those which
do not directly support OPA.
Signed-off-by: jcoenraadts <joel@bytelab.com>
* Changes reserved name "OPA Control Plane" to "Data Control Plane"
This change is to avoid confusion with the officially released OPA Control Plane
Signed-off-by: jcoenraadts <joel@bytelab.com>
---------
Signed-off-by: jcoenraadts <joel@bytelab.com>
Co-authored-by: jcoenraadts <joel@bytelab.com>
In previous version of the docs, S3 and git were listed as separate,
supported types of datasources, which was unclear. Added changes state that there
is only one type supported, extend example how to use it and add link
to Secrets section.
Signed-off-by: Igor Rodzik <igor.rodzik@gmail.com>
Save 1 alloc per invocation of the `split` built-in function by
using `strings.Cut` instead of `strings.Split`, thus avoiding
creating an intermediate string slice. Added a `SplitMap` helper
for doing this elsewhere in our code where `strings.Split` could
be replaced.
Signed-off-by: Anders Eknert <anders@eknert.com>
Stephan Renatus