Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

policy: FallbackEvaluate disagrees with the OPA engine on enabled defaults, AND/OR semantics, and rootDirectory

Open
  • Is something wrong?
#115 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
backend, security

Research direction

Start by comparing enabledForRego and enabledForFallback in rego.go:42, then read the constraint checks in policy.go:360 and policy.go:375 alongside the Rego evaluator's corresponding behavior. Check the existing path-containment logic and tests for rootDirectory. Done means both evaluators agree on defaults and AND semantics, and fallback evaluation enforces root-directory boundaries.

Written by the indexing model from the issue text.

Description

bug help wanted

Problem

Three related semantic-drift issues between the primary Rego/OPA evaluator and the pure-Go FallbackEvaluate path in packages/policy:

  1. rego.go:42 — enabledForRego and enabledForFallback disagree on which features/rules are considered enabled by default, so the same configuration can be interpreted differently depending on which evaluator handles it.
  2. policy.go:375 — FallbackEvaluate combines multiple constraints with OR logic where the Rego policy combines the equivalent constraints with AND, so a rule that should require all conditions to hold can be satisfied by just one of them under the fallback evaluator.
  3. policy.go:360 — rootDirectory constraint checking is entirely unimplemented in FallbackEvaluate (a no-op / always-true), while the Rego engine enforces it.

Impact

Whenever the fallback evaluator is used instead of OPA (e.g. OPA unavailable, or a deployment configured to run fallback-only), policies can be enforced with meaningfully looser semantics than intended: features assumed disabled by default may be enabled, AND-combined constraints degrade to OR, and rootDirectory confinement does nothing at all. This is a silent policy-weakening bug whose effect is invisible to anyone validating policy behavior solely against the Rego engine.

Repro

  1. Compare enabledForRego and enabledForFallback's default-enabled sets directly; find at least one rule/feature where they differ.
  2. Write a policy rule with two constraints that must both hold (AND semantics in Rego); evaluate the same policy via FallbackEvaluate with only one constraint satisfied and observe it is allowed, where the Rego path would deny it.
  3. Set a rootDirectory constraint and evaluate a path outside it via FallbackEvaluate; observe it is allowed, where the Rego engine would deny it.

Suggested fix

Audit enabledForRego vs enabledForFallback and make them share a single source of truth for default-enabled rules rather than two independently maintained lists. Change FallbackEvaluate's constraint combination at :375 from OR to AND to match the Rego semantics (or, better, extract the combination logic into a shared helper exercised by both evaluators). Implement rootDirectory checking in FallbackEvaluate using the same path-containment logic as the Rego engine (see the related rootDirectory issue for the Rego side's own boundary bug, which the fallback implementation should not blindly copy).

Dominant language
Go
Stars
157
Forks
19
Avg merge
4h 32m
Merged PRs (30d)
96

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from solongate/agent-security

All issues in solongate/agent-security

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.