Please note: We take Cosmian KMS's security and our users' trust very seriously. If you believe you have found a security issue in Cosmian KMS, please read our security policy and responsibly disclose by contacting us at [email protected].
First: if you're unsure or afraid of anything, just ask or submit the issue or pull request anyways. You won't be yelled at for giving it your best effort. The worst that can happen is that you'll be politely asked to change something. We appreciate any sort of contributions, and don't want a wall of rules to get in the way of that.
That said, if you want to ensure that a pull request is likely to be merged, talk to us! You can find out our thoughts and ensure that your contribution won't clash or be obviated by Cosmian KMS's normal direction. A great way to do this is via GitHub Issues or GitHub Discussions.
This section will cover what we're looking for in terms of reporting issues.
By addressing all the points we're looking for, it raises the chances we can quickly merge or address your contributions.
• Make sure you test against the latest released version. It is possible we already fixed the bug you're experiencing.
Even better is if you can test against the develop branch, as bugs are regularly fixed but new versions are only
released periodically.
• Provide steps to reproduce the issue, and if possible include the expected results as well as the actual results. Please provide text, not screen shots!
• If you are seeing an internal Cosmian KMS error (a status code of 5xx), please be sure to post relevant parts of (or the entire) Cosmian KMS log, as often these errors are logged on the server but not reported to the user.
• If you experienced a panic, please create a gist of the entire generated crash log for us to look at. Double check no sensitive items were in the log.
• Respond as promptly as possible to any questions made by the Cosmian KMS team to your issue.
-
The issue is reported.
-
The issue is verified and categorized by a Cosmian KMS collaborator. Categorization is done via tags. For example, bugs are marked as "bugs".
-
Unless it is critical, the issue may be left for a period of time (sometimes many weeks), giving outside contributors -- maybe you!? -- a chance to address the issue.
-
The issue is addressed in a pull request or commit. The issue will be referenced in the commit message so that the code that fixes it is clearly linked.
-
The issue is closed.
-
Issues that are not reproducible and/or not gotten responses for a long time are stale issues. In order to provide faster responses and better engagement with the community, we strive to keep the issue tracker clean and the issue count low. In this regard, our current policy is to close stale issues after 30 days.
Closed issues will still be indexed and available for future viewers. If users feel that the issue is still relevant, we encourage reopening them.
When submitting a PR you should reference an existing issue. If no issue already exists, please create one. This can be skipped for trivial PRs like fixing typos.
Creating an issue in advance of working on the PR can help to avoid duplication of effort, e.g. maybe we know of existing related work. Or it may be that we can provide guidance that will help with your approach.
Your pull request should have a description of what it accomplishes, how it does so, and why you chose the approach you did. PRs should include unit tests that validate correctness and the existing tests must pass. Follow-up work to fix tests does not need a fresh issue filed.
Someone will do a first pass review on your PR making sure it follows the guidelines in this document. If it doesn't we'll mark the PR incomplete and ask you to follow up on the missing requirements.
Create a file CHANGELOG/<your-branch-name-with-slashes-replaced-by-underscores>.md and add a one-line summary of
your change. For example, for branch fix/my-bug create CHANGELOG/fix_my-bug.md.
Use one of these section headers: Features, Bug Fixes, Build, Refactor, Documentation, Testing, CI,
Security. Group related entries under a sub-feature or component if applicable. See existing files in
CHANGELOG/ for examples.
The UI is a React 19 + TypeScript + Vite app located in ui/. It mirrors the ckms CLI — every CLI feature should
have a corresponding UI action.
For new features, open an issue first describing the use case and approach - A Cosmian KMS collaborator will review it and might assist you in coding the feature if it's accepted. Bug fixes can go straight to a PR.
All three test layers must pass before merging (E2E Playwright, Vitest integration, Vitest unit). See §8 Web UI & Playwright E2E tests in AGENTS.md for how to run them.
If you have never worked with Rust before, you will have to complete the following steps:
- Install Rust using rustup
- Install the required stable toolchain:
rustup toolchain install 1.90.0 - Install required components:
rustup component add rustfmt clippy --toolchain 1.90.0 - Build the project:
cargo build --release
For build commands and local setup, see Quick start in the README. For Nix-based reproducible builds and CI, see §1 Build & test cheatsheet and §13 Nix packaging in AGENTS.md.
If you are using an AI coding assistant that does not natively support AGENTS.md (e.g. Claude Code, at the time of
writing), create a symbolic link so it picks up the agent instructions automatically:
ln -s AGENTS.md CLAUDE.mdBefore submitting a pull request, please ensure that:
• All existing tests pass: cargo test --workspace --lib
• Your code is properly formatted: cargo fmt --check
• Your code passes clippy lints: cargo clippy --workspace --all-targets --all-features
• If you've added new functionality, include appropriate unit and/or integration tests
For database-specific testing, you may need to set up local database instances. See §1 Database test environment in AGENTS.md for details.
We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution.
Learn more about the CLA and sign it here
This project adheres to the principles of respectful and inclusive collaboration. We expect all contributors to:
• Be respectful and constructive in discussions • Focus on the technical aspects of contributions • Help maintain a welcoming environment for all contributors • Report any behavior that violates these principles to [email protected]
If you need help with your contribution:
• Check the documentation for technical guides • Search existing issues for similar problems • Open a new issue with the "question" label • Contact us at [email protected] for general inquiries
Thank you for contributing to Cosmian KMS!