Thanks for helping build pasu. It's a security tool, so a few rules keep it trustworthy. (Maintainer/AI working rules live in CLAUDE.md; this is the short version for contributors.)
Working with a coding agent? Point it at AGENTS.md — it has the
orientation, build/test commands, and step-by-step recipes for common changes
(under .github/skills/).
- Conventional Commits:
type(scope): description. Scope aligns with area —proxy/egress/ebpf/rules/ui/audit/core/ci/docs. - DCO sign-off: commit with
git commit -s(you certify you wrote it). Contribute under your own name — no AI-authorship attribution. - Branch → PR → CI green → merge. No direct pushes to
main. - One PR = one problem. Keep changes isolated and reviewable.
- Rule/logic changes need regression tests: fail before the fix, pass after.
- TP + TN pairs: prove a dangerous action is blocked and a legitimate one still passes (no over-blocking / false-positive regressions).
- Bypass tests: prove enforcing > cooperative — e.g. a tool that bypasses the in-process hook with its own egress is still dropped by the kernel.
- fail-closed: if the guard cannot operate, deny. Don't add fail-open paths for convenience.
| target | toolchain | command |
|---|---|---|
| portable crates (core, rules, ui, audit, proxy) | stable | cargo test |
| eBPF stack (egress, ebpf) | Linux + nightly + bpf-linker |
cargo build -p pasu-egress |
The eBPF stack is kept out of default-members, so cargo test and the stable
CI job stay green without a bpf toolchain.
- Keep crates separate; everything depends only on
pasu-core(acyclic graph). - Implementations live behind traits (
RuleEngine,Layer,Approver,AuditSink) so they stay swappable. - If a change would break a crate boundary or a trait abstraction — stop and propose a redesign rather than coupling things ad hoc.
- Bugs / features → open a GitHub Issue.
- Design / questions → open a GitHub Discussion.
- Security vulnerabilities → do not open a public issue; see SECURITY.md.