|
| 1 | +# Contributing |
| 2 | + |
| 3 | +Contributions that improve reproducibility, documentation, test coverage, |
| 4 | +hardware support, or defensive security analysis are welcome. |
| 5 | + |
| 6 | +## Principles |
| 7 | + |
| 8 | +Changes should: |
| 9 | + |
| 10 | +- preserve safe-failure behavior; |
| 11 | +- avoid weakening verification, recovery, or rollback checks; |
| 12 | +- remain reproducible on documented hardware; |
| 13 | +- include tests for security-relevant behavior; |
| 14 | +- use English for source comments, documentation, reports, and user-facing output; |
| 15 | +- avoid personal paths, hostnames, credentials, and private device data; |
| 16 | +- explain the technical reason for the change. |
| 17 | + |
| 18 | +## Development workflow |
| 19 | + |
| 20 | +1. Create a focused branch. |
| 21 | +2. Keep each change limited to one technical purpose. |
| 22 | +3. Run the relevant host tests and static checks. |
| 23 | +4. Run hardware-in-the-loop tests when firmware or flashing behavior changes. |
| 24 | +5. Update documentation when observable behavior changes. |
| 25 | +6. Review the diff for private information and generated artifacts. |
| 26 | + |
| 27 | +## Commit messages |
| 28 | + |
| 29 | +Use concise imperative commit subjects, for example: |
| 30 | + |
| 31 | +- `Add manifest boundary validation` |
| 32 | +- `Document HIL restore guarantees` |
| 33 | +- `Reject invalid application vector tables` |
| 34 | + |
| 35 | +Avoid vague subjects such as `fix`, `update`, or `changes`. |
| 36 | + |
| 37 | +## Security-sensitive changes |
| 38 | + |
| 39 | +Changes to image verification, key handling, metadata selection, rollback |
| 40 | +policy, flash protection, recovery, or update installation require: |
| 41 | + |
| 42 | +- a description of the threat being addressed; |
| 43 | +- negative tests; |
| 44 | +- safe-failure verification; |
| 45 | +- documentation of residual risk. |
| 46 | + |
| 47 | +## Generated files |
| 48 | + |
| 49 | +Do not commit compiler output, virtual environments, caches, temporary logs, |
| 50 | +private signing material, or complete local HIL run directories. |
| 51 | + |
| 52 | +Curated validation evidence may be added under a dedicated report directory |
| 53 | +when it is anonymized, reproducible, and required to support a documented |
| 54 | +result. |
| 55 | + |
| 56 | +## Licensing |
| 57 | + |
| 58 | +By submitting a contribution, you agree that it may be distributed under the |
| 59 | +BSD 3-Clause License used by this repository. |
0 commit comments