Difficulty: Expert
Type: Security / Architecture
Background: Once Issue #22 wires governance-engine's evaluateRule() into the live checkAccess() path via a RuleProvider, community-defined governance rules (arbitrary ASTs, per ast.ts) become part of the hot path for every access decision in communities that use them. evaluator.ts presumably walks/interprets the RuleNode AST directly against a GovernanceContext.
Problem: Community-authored rules are, by definition, less trusted input than the system's own static policy types — a maliciously or accidentally crafted rule AST (e.g. one designed to be deeply/pathologically nested, or one referencing an expensive contribution-score computation in a loop-like AST pattern if the AST format supports any form of repetition/recursion) could degrade checkAccess()'s latency or resource usage for the entire community, or in the worst case for the whole API process, since there's no evident sandboxing, timeout, or resource-limiting around evaluateRule()'s execution today.
Expected outcome: A hardened execution model for governance rule evaluation: a hard evaluation-time budget (the evaluator aborts and the provider returns ABSTAIN or a clear error-coded DENY if a rule doesn't complete within a strict time budget, e.g. a few milliseconds), a hard bound on AST complexity/depth enforced at validateRuleAST() time (rejecting rules that could never execute within budget before they're ever stored), and isolation from any shared mutable state so one community's rule evaluation cannot affect another's.
Suggested implementation: Audit packages/governance-engine/src/evaluator.ts and ast.ts for any recursive or unbounded-iteration constructs; add explicit depth/complexity limits to validateRuleAST() (rejecting overly deep or complex ASTs at rule-creation time, before they can ever be evaluated in the hot path); wrap evaluateRule() invocations in the RuleProvider (from Issue #22) with a strict timeout (e.g. using a worker-thread-based sandbox if the evaluator does anything beyond pure, terminating AST interpretation, or a simple wall-clock budget check with periodic yield points if it's a straightforward tree-walk interpreter with no external calls); add load-testing/benchmark coverage specifically simulating adversarially-crafted rules to confirm the system degrades gracefully rather than falling over.
Acceptance criteria:
validateRuleAST() rejects ASTs beyond a documented, justified complexity/depth threshold.- Evaluation of any accepted rule is provably bounded in time (a test constructs the most expensive AST
validateRuleAST would still accept and confirms evaluation completes well within the enforced budget).
- A load test demonstrates that a community with a maximally-complex-but-valid governance rule does not measurably degrade
checkAccess() latency for unrelated communities.
- The chosen resource-limiting mechanism (timeout, depth limit, or sandboxing) and its rationale are documented in
GOVERNANCE_ENGINE_IMPLEMENTATION.md or a new security-focused doc.
Likely affected files: packages/governance-engine/src/validator.ts, packages/governance-engine/src/evaluator.ts, the RuleProvider implementation from Issue #22, new load-test file.
Labels: security, performance, policy-engine, help wanted, GrantFox OSS, Maybe Rewarded, Official Campaign | FWC26
Difficulty: Expert
Type: Security / Architecture
Background: Once Issue #22 wires
governance-engine'sevaluateRule()into the livecheckAccess()path via aRuleProvider, community-defined governance rules (arbitrary ASTs, perast.ts) become part of the hot path for every access decision in communities that use them.evaluator.tspresumably walks/interprets theRuleNodeAST directly against aGovernanceContext.Problem: Community-authored rules are, by definition, less trusted input than the system's own static policy types — a maliciously or accidentally crafted rule AST (e.g. one designed to be deeply/pathologically nested, or one referencing an expensive contribution-score computation in a loop-like AST pattern if the AST format supports any form of repetition/recursion) could degrade
checkAccess()'s latency or resource usage for the entire community, or in the worst case for the whole API process, since there's no evident sandboxing, timeout, or resource-limiting aroundevaluateRule()'s execution today.Expected outcome: A hardened execution model for governance rule evaluation: a hard evaluation-time budget (the evaluator aborts and the provider returns
ABSTAINor a clear error-codedDENYif a rule doesn't complete within a strict time budget, e.g. a few milliseconds), a hard bound on AST complexity/depth enforced atvalidateRuleAST()time (rejecting rules that could never execute within budget before they're ever stored), and isolation from any shared mutable state so one community's rule evaluation cannot affect another's.Suggested implementation: Audit
packages/governance-engine/src/evaluator.tsandast.tsfor any recursive or unbounded-iteration constructs; add explicit depth/complexity limits tovalidateRuleAST()(rejecting overly deep or complex ASTs at rule-creation time, before they can ever be evaluated in the hot path); wrapevaluateRule()invocations in theRuleProvider(from Issue #22) with a strict timeout (e.g. using a worker-thread-based sandbox if the evaluator does anything beyond pure, terminating AST interpretation, or a simple wall-clock budget check with periodic yield points if it's a straightforward tree-walk interpreter with no external calls); add load-testing/benchmark coverage specifically simulating adversarially-crafted rules to confirm the system degrades gracefully rather than falling over.Acceptance criteria:
validateRuleAST()rejects ASTs beyond a documented, justified complexity/depth threshold.validateRuleASTwould still accept and confirms evaluation completes well within the enforced budget).checkAccess()latency for unrelated communities.GOVERNANCE_ENGINE_IMPLEMENTATION.mdor a new security-focused doc.Likely affected files:
packages/governance-engine/src/validator.ts,packages/governance-engine/src/evaluator.ts, theRuleProviderimplementation from Issue #22, new load-test file.Labels:
security,performance,policy-engine,help wanted,GrantFox OSS,Maybe Rewarded,Official Campaign | FWC26