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

panels: rule match editor collapses Allowed/Denied lists and ignores RootDirectory when flagging blanket rules

Open
  • Is something wrong?
#151 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
1-2 days
Newbie friendliness
58/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
security

Research direction

Start by reading policies_rule.go around lines 110 and 236, then trace how the rule match editor stores Allowed and Denied values and how the policy engine determines effective scope. Reproduce both cases with a rule containing entries in both lists and with a specific RootDirectory. Done when editing either list preserves the other and the blanket warning reflects the rule's effective scope.

Written by the indexing model from the issue text.

Description

bug help wanted

Problem

Two related issues in packages/tui/panels:

  1. policies_rule.go:110 — the match editor's rendering/editing logic for a rule's Allowed and Denied value lists shares state in a way that collapses them into a single effective list when editing, so changes meant for one list can overwrite or merge into the other.
  2. policies_rule.go:236 — the guard that warns the user they are about to save an overly broad "blanket" rule checks only the Allowed/Denied selectors and does not take RootDirectory into account, so a rule that is actually meaningfully scoped by RootDirectory is incorrectly flagged as blanket, while conversely a rule with an unset RootDirectory that should be flagged may not be, if the logic's omission cuts both ways depending on implementation.

Impact

The collapsed Allowed/Denied editing state can cause a user to unintentionally corrupt one list while editing the other, resulting in a saved rule that doesn't match what was intended. The blanket-rule warning being blind to RootDirectory either produces false-positive warnings that train users to ignore the warning, or misses genuinely overly broad rules, in either case undermining the warning's usefulness as a safety check before saving a rule.

Repro

  1. Open the rule match editor for a rule with both Allowed and Denied entries, edit the Allowed list, save, and observe the Denied list has been altered/collapsed as a side effect.
  2. Create a rule with a narrow RootDirectory but broad Allowed/Denied selectors (or vice versa) and observe the blanket-rule warning's determination does not reflect the actual effective scope once RootDirectory is considered.

Suggested fix

Give the Allowed and Denied lists independent editing state in the match editor (e.g. separate backing fields/widgets) so editing one cannot bleed into the other. Extend the blanket-rule check to factor in RootDirectory: a rule scoped to a specific, non-root directory should not be flagged as blanket purely based on its Allowed/Denied selectors, and the check should use the same effective-scope logic the policy engine itself uses when deciding how broad a rule actually is.

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

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.