|
| 1 | +<!-- SPDX-License-Identifier: GPL-3.0-or-later --> |
| 2 | + |
| 3 | +# Contributing to Vault |
| 4 | + |
| 5 | +Thank you for your interest. Please read this document before opening an |
| 6 | +issue or pull request — it sets honest expectations for both sides so no |
| 7 | +one's time is wasted. |
| 8 | + |
| 9 | +## Project Stance |
| 10 | + |
| 11 | +Vault is a subproject of **Spacecraft Software**, a personal hobby project. It |
| 12 | +is shaped around the maintainer's own use case and developed at hobby pace. |
| 13 | + |
| 14 | +This is **not** a community-driven project, but external input is welcome |
| 15 | +and appreciated within the bounds set out below. |
| 16 | + |
| 17 | +## What Is Welcome |
| 18 | + |
| 19 | +- **Bug reports** — clear, reproducible, with environment details (OS, kernel, |
| 20 | + Rust toolchain version, shell, server type — bitwarden.com vs Vaultwarden, |
| 21 | + relevant config). For security-sensitive bugs see *Reporting Security Issues* |
| 22 | + below. |
| 23 | +- **Suggestions** — features, refactors, naming proposals (must conform to |
| 24 | + Spacecraft Software Standard §2 — aerospace / sci-fi / AI naming), design |
| 25 | + feedback. |
| 26 | +- **Pull requests** — small, focused, and aligned with the Spacecraft Software |
| 27 | + Standard and Vault's PRD. |
| 28 | +- **Documentation fixes** — typos, inaccuracies, broken links, clarifications, |
| 29 | + translations. |
| 30 | +- **Test coverage improvements** — almost always merge-worthy. |
| 31 | + |
| 32 | +## What Is Not Guaranteed |
| 33 | + |
| 34 | +- **PR acceptance.** Direction, scope, and quality bar are set by the |
| 35 | + maintainer alone. A submitted contribution is not a guaranteed merge, even |
| 36 | + if it is correct, well-written, and passes CI. If a PR is not accepted, that |
| 37 | + is a judgment of fit, not of the work. |
| 38 | +- **Response time.** This is a hobby project. Expect responses on the order of |
| 39 | + days to weeks, not hours. |
| 40 | +- **Roadmap influence.** Suggestions may inform direction but do not override |
| 41 | + the maintainer's plans documented in [`PRD.md`](./PRD.md). |
| 42 | +- **API stability for in-progress work.** Pre-1.0 versions may break in any |
| 43 | + release. |
| 44 | + |
| 45 | +## Before Opening a PR |
| 46 | + |
| 47 | +1. **Open an issue first** for non-trivial changes. Discuss the design before |
| 48 | + writing code. |
| 49 | +2. **Read the Spacecraft Software Standard** and the Vault [`PRD.md`](./PRD.md). |
| 50 | + Memory safety → performance → hardened security, in that order. Rust where |
| 51 | + viable. POSIX-compliant CLI. GPL-3.0-or-later with SPDX headers on every |
| 52 | + source file. |
| 53 | +3. **Match the CLI Standard** (SFRS v1.0.0) for anything touching `vault-cli`. |
| 54 | +4. **Run the full test suite locally.** PRs that don't pass CI will not be |
| 55 | + reviewed. |
| 56 | +5. **Use the project's preferred toolchain.** Format with `rustfmt`, lint with |
| 57 | + `clippy -- -D warnings`, and run `cargo audit` for any added dependency. |
| 58 | +6. **Sign-off your commits** (`git commit -s`) under the |
| 59 | + [Developer Certificate of Origin](https://developercertificate.org/). |
| 60 | +7. **Cryptographically sign your commits** — Spacecraft Software Standard §6.3 |
| 61 | + requires every commit to a Spacecraft Software remote to be signed and show |
| 62 | + "Verified" on GitHub. Ed25519 SSH signing is the current default. |
| 63 | + |
| 64 | +## Security-Sensitive Areas |
| 65 | + |
| 66 | +Vault handles credential material. Extra care is expected in: |
| 67 | + |
| 68 | +- Anything touching the master key, KDF, or EncString parsing (`vault-core`). |
| 69 | +- The agent's IPC boundary (`vault-ipc`, `vault-agent`). |
| 70 | +- Clipboard handling. |
| 71 | +- Network code (`vault-api`). |
| 72 | + |
| 73 | +Changes in these areas should include unit tests; non-trivial changes should |
| 74 | +include integration tests and, where applicable, fuzz harness updates. |
| 75 | + |
| 76 | +## Commit Style |
| 77 | + |
| 78 | +- Conventional Commits prefix (`feat:`, `fix:`, `docs:`, `refactor:`, |
| 79 | + `test:`, `chore:`, `perf:`, `build:`, `ci:`). |
| 80 | +- Subject ≤ 72 characters, imperative mood ("add" not "added"). |
| 81 | +- Body wrapped at 72 columns; explain *why*, not just *what*. |
| 82 | +- Reference issues by number (`Closes #42`). |
| 83 | + |
| 84 | +## Forking |
| 85 | + |
| 86 | +If your needs diverge from the maintainer's, or you want to take Vault in a |
| 87 | +different direction, **fork it**. That is exactly what GPL-3.0-or-later is |
| 88 | +for. The only constraints are those imposed by the license itself: keep the |
| 89 | +source open and under a compatible license, preserve copyright notices, and |
| 90 | +pass the same freedoms downstream. |
| 91 | + |
| 92 | +## Reporting Security Issues |
| 93 | + |
| 94 | +For security-sensitive bugs, do **not** open a public issue. Email |
| 95 | +<Mohamed.Hammad@SpacecraftSoftware.org> with details. PGP key available on |
| 96 | +request. |
| 97 | + |
| 98 | +A coordinated-disclosure window of 90 days from acknowledgment is the default; |
| 99 | +this can be shortened or lengthened by mutual agreement. |
| 100 | + |
| 101 | +## License of Contributions |
| 102 | + |
| 103 | +By submitting a contribution, you agree that it will be licensed under |
| 104 | +**GPL-3.0-or-later**, the same terms as the project. Contributions that cannot |
| 105 | +be licensed under GPL-3.0-or-later cannot be accepted. |
| 106 | + |
| 107 | +You retain copyright in your contributions; no CLA is required. |
| 108 | + |
| 109 | +--- |
| 110 | + |
| 111 | +**Maintainer:** Mohamed Hammad <Mohamed.Hammad@SpacecraftSoftware.org> |
| 112 | +**License:** GPL-3.0-or-later |
| 113 | +**Website:** <https://Vault.SpacecraftSoftware.org/> |
| 114 | + |
| 115 | +*--- Forged in Spacecraft Software ---* |
0 commit comments