Contributing to Glutton

Thanks for considering a contribution. Glutton is a security tool, so small source-verified changes are easier to review than broad rewrites.

See Getting started for the toolchain, Spicy/HILTI, and Glutton build steps.

Guidelines

• Pick an issue from the tracker. Useful labels: good first issue, help wanted, protocol, enhancement. Reproduce older issues against main before starting. For protocol work, read Extension system, Adding a protocol, and Spicy cheatsheet first to gauge effort.
• Comment before you start so a maintainer can confirm scope or redirect.
• Keep PRs small and source-verified. Split large work into a thin first slice.
• Add tests beside the package you change.
• Update docs in the same PR when behavior changes:
  • Build/CI/Docker or Go version → Getting started
  • Config defaults or rules behavior → Configuration
  • Handler registration or protocol behavior → Architecture, Extension system, FAQ
  • Producer event fields → Logging and producers
  • Spicy parser coverage → Spicy cheatsheet

Code style and PRs

• Format Mirror the structure of existing handlers in protocols/tcp/ and protocols/udp/.
• Respect the boundary: parsing belongs in .spicy files, protocol logic in Go. Never commit generated parser artifacts — they're git-ignored.
• Test before pushing: run go test ./protocols/... ./rules/... while iterating, and the full CC=clang CXX=clang++ go test ./... (Spicy must be installed) before opening a PR. If you changed any .spicy file, run make spicy first so tests pick up the regenerated parser.
• Write a focused PR: describe what changed, how you tested it, and which docs moved with it. Keep unrelated cleanup in its own PR.