|
| 1 | +# Contributing To Fluxheim |
| 2 | + |
| 3 | +Fluxheim is a fun Rust/Pingora project, but it is still security-sensitive |
| 4 | +infrastructure. Contributions are welcome when they keep the project small, |
| 5 | +clear, tested, and honest about what is stable. |
| 6 | + |
| 7 | +## License |
| 8 | + |
| 9 | +Fluxheim is licensed under the European Union Public Licence 1.2. By |
| 10 | +contributing, you agree that your contribution is provided under the same |
| 11 | +license. |
| 12 | + |
| 13 | +## Development Setup |
| 14 | + |
| 15 | +Use the pinned Rust toolchain from `rust-toolchain.toml`. |
| 16 | + |
| 17 | +```bash |
| 18 | +cargo build |
| 19 | +cargo test |
| 20 | +``` |
| 21 | + |
| 22 | +Useful reduced builds: |
| 23 | + |
| 24 | +```bash |
| 25 | +cargo build --no-default-features --features proxy |
| 26 | +cargo build --no-default-features --features web |
| 27 | +cargo build --no-default-features --features proxy,load-balancer |
| 28 | +``` |
| 29 | + |
| 30 | +## Checks |
| 31 | + |
| 32 | +Before opening a pull request, run: |
| 33 | + |
| 34 | +```bash |
| 35 | +scripts/checks.sh |
| 36 | +``` |
| 37 | + |
| 38 | +For release-sensitive changes, run: |
| 39 | + |
| 40 | +```bash |
| 41 | +scripts/release_checks.sh |
| 42 | +``` |
| 43 | + |
| 44 | +Run the rootless Podman smoke when changing the container image or deployment |
| 45 | +files: |
| 46 | + |
| 47 | +```bash |
| 48 | +FLUXHEIM_RELEASE_PODMAN=1 scripts/release_checks.sh |
| 49 | +``` |
| 50 | + |
| 51 | +## Security-Sensitive Changes |
| 52 | + |
| 53 | +Treat these areas as high risk: |
| 54 | + |
| 55 | +- request parsing and body limits; |
| 56 | +- TLS and certificate handling; |
| 57 | +- proxy routing and upstream selection; |
| 58 | +- cache keys, cache admission, and purge endpoints; |
| 59 | +- admin API, snapshots, and rollback; |
| 60 | +- logging, metrics, and privacy mode; |
| 61 | +- dependency updates. |
| 62 | + |
| 63 | +Do not post exploitable security details in public issues. Follow |
| 64 | +[SECURITY.md](../SECURITY.md). |
| 65 | + |
| 66 | +## Dependency Policy |
| 67 | + |
| 68 | +Fluxheim uses `deny.toml`, `cargo-deny`, and `cargo-audit`. |
| 69 | + |
| 70 | +When adding or updating crates: |
| 71 | + |
| 72 | +- use crates.io releases unless there is a strong reason not to; |
| 73 | +- avoid git dependencies; |
| 74 | +- check maintenance status and license; |
| 75 | +- keep `Cargo.lock` updated; |
| 76 | +- run `cargo deny check` and `cargo audit`. |
| 77 | + |
| 78 | +## Design Guidelines |
| 79 | + |
| 80 | +- Prefer existing local patterns over new abstractions. |
| 81 | +- Keep modules feature-gated when they change the threat model. |
| 82 | +- Keep default builds focused on stable core behavior. |
| 83 | +- Do not make legacy or experimental protocols part of normal request paths. |
| 84 | +- Document stable, beta, experimental, and research features honestly. |
| 85 | + |
| 86 | +## Pull Requests |
| 87 | + |
| 88 | +Good pull requests are small enough to review and include: |
| 89 | + |
| 90 | +- a clear summary; |
| 91 | +- tests for behavior changes; |
| 92 | +- docs or examples when user-facing behavior changes; |
| 93 | +- security notes for risky areas. |
| 94 | + |
| 95 | +Large features should start with a roadmap or design-doc update before code. |
0 commit comments