Johan Fylling

Your find in #6689 is unrelated to this issue. Nevertheless, great find and fix! 👍 😃

> I would suggest taking a stand here instead. The title of this issue suggests as much :) My intention was to bring this up for discussion. But in retrospect,...

Is this a bug, or by design? The `opa build` command will respect the passed capabilities file. One could reason that it's only during commands like `check` and `build` we...

If this isn't a bug, and should be corrected, [this](https://github.com/open-policy-agent/opa/blob/eade10ae0e0d3436b146cc2c942387c26cbbfd5c/rego/rego.go#L1839C32-L1839C32) is where the capabilities are dropped.

Yes, it's a peculiar limitation if by design. And I'd honestly be surprised if anyone expected `eval` to behave differently than `build` and `check`. Especially since it's undocumented.

> it makes sense for that to have a capabilities flag added if that has an impact on parsing? yes, I suppose so. All it'd do with the current set...

I was imagining the former: an inline capabilities block.

Could we even simplify it further? Simply using a solitary `@` as metadata prefix is easier to type (marginally 😄), and supports being commented out: ``` @ title: foo @...

Yes @ashutosh-narkar. I'm thinking a boolean attribute to allow all or no file refs might be enough, though.

I think file $refs should probably be disabled by default, and something you need to opt into. But I also don't think the security concern is very big here.