Governance

Craton HSM is stewarded by Craton Inc. (also trading as Craton Software Company) with contributions from the open-source community. This page explains the decision-making model, maintainer roles, and how authority is exercised across the Core and Enterprise repositories.

Project Structure

Both repositories share the same maintainer team, release cadence, and security-response process. The license difference is deliberate and is covered in license.

Roles

Core Team (@craton-inc/core-team)

The core team holds write access on both repositories, dispatches releases, and owns the architectural direction. It is the default reviewer on every pull request.

Core-team responsibilities:

• Reviewing and merging pull requests.
• Triaging issues and coordinating security reports.
• Release management and signing of Git tags.
• Architectural decisions and ADR-style discussions.

Security Team (@craton-inc/security)

A separate, stricter team that reviews changes to security-sensitive paths. A PR touching any of the paths below cannot merge until both the core team and the security team have approved; this is enforced by branch protection and the CODEOWNERS file.

Security-team membership is granted internally by Craton Inc. and is not available through community contribution alone.

Contributors

Community members who submit pull requests, report issues, or participate in discussions. A new contributor signs the CLA via the CLA Assistant bot on their first PR and is thereafter on the same footing as any other community contributor.

Decision-Making

Minor changes

Bug fixes, documentation, dependency patch bumps, and small enhancements merge on one core-team approval plus any applicable CODEOWNERS approval, provided all required status checks pass.

Significant changes

Changes that affect the public PKCS#11 ABI, the security model, the cryptographic implementations, or the architectural design require:

1. A GitHub issue or discussion describing the motivation.
2. Approval from two core-team members.
3. Crypto review by a security-team member if the change touches a security-sensitive path.
4. Documentation update in the same PR.

Breaking changes

Changes that break the PKCS#11 ABI, change key serialization formats, or alter security behaviour additionally require:

• A CHANGELOG.md entry under ## [Unreleased] with migration instructions.
• A migration-guide update (Enterprise: MIGRATION.md).
• A version bump per semantic versioning. Pre-1.0 breaking changes are permitted in minor releases and are always called out in the changelog.

Architectural changes

New crates, public-trait signature changes, MSRV bumps, and dependencies with non-trivial transitive surface require two core-team approvals plus a linked ROADMAP.md or ADR entry.

Tie-breaking

Unresolved disagreement after 10 business days is escalated to the project lead, currently staffed by the core-team rotation.

Maintainers

The authoritative list of maintainers is in each repository's .github/CODEOWNERS file. The Enterprise MAINTAINERS.md adds the review-SLA table, release-process runbook, backport policy, dependency authority, and revert policy.

Becoming a maintainer

Maintainership is granted on sustained, high-quality contribution:

• At least 10 merged non-trivial PRs across at least two crates, over a minimum of six months.
• Demonstrated constructive review activity on other contributors' PRs.
• Familiarity with the FIPS boundary, the Raft / KMIP / auth threat model, and the BSL-1.1 licensing constraints.
• Agreement to the Code of Conduct and the CLA.

A core-team member opens a private discussion nominating the candidate; the core team holds lazy consensus for 10 business days; any objection pauses the process pending resolution. On approval, the candidate is added to @craton-inc/core-team and granted repository permissions.

Inactive-maintainer policy

A maintainer inactive for 6 consecutive months (no merges, reviews, or issue triage) is moved to Emeritus. Reinstatement is handled the same way as a new nomination, without the 10-PR threshold.

Maintainers may step down voluntarily at any time by opening a PR that removes their entry from MAINTAINERS.md and CODEOWNERS.

Voting and Lazy Consensus

The project uses lazy consensus for maintainer nominations and minor process changes: an explicit approval from any core-team member is sufficient, and silence from the rest of the team is taken as assent after the 10-business-day window elapses. Any objection pauses the process until it is resolved.

Major process changes (new crate, new license, change of governance document) are not handled by lazy consensus — they require explicit approval from a majority of the core team.

Release Approval

Release cutting is restricted to the core team. A release requires:

1. CHANGELOG.md updated under a dated version heading.
2. All CI jobs green on the release commit (or the release branch).
3. cargo audit and cargo deny check clean, or documented advisory waivers.
4. Security-team sign-off if any security-sensitive path changed since the previous tag.
5. A GPG-signed annotated Git tag pushed to origin.

Patch releases (0.1.x → 0.1.x+1) may skip the release-branch step for low-risk fixes; minor and major releases always use a release branch. See the Enterprise MAINTAINERS.md release section for the full runbook.

Versioning

Both projects follow Semantic Versioning:

• MAJOR — breaking changes to the PKCS#11 ABI or key formats.
• MINOR — new features, new mechanisms, backward-compatible additions.
• PATCH — bug fixes, security patches, documentation updates.

Pre-1.0 versions (current for both Core and Enterprise) may include breaking changes in minor releases, always documented in the changelog.

Security Governance

• Vulnerabilities are reported privately, not in public issues. See security-advisories for the channels and timelines.
• Response SLA: 48 h (Core) / 2 business days (Enterprise) acknowledgement; 1 week (Core) / 7 days (Enterprise) assessment; patch within 30 days for critical issues.
• Security fixes are backported per the Enterprise backport policy summarised in changelog.

Code of Conduct

All participants follow the Contributor Covenant 2.1. Enforcement reports go to dev@craton.com.ar. Community leaders have the responsibility and the authority to remove, edit, or reject contributions that violate the code; escalations follow the Community-Impact Guidelines (correction → warning → temporary ban → permanent ban).

Trademark Policy

"Craton" and "Craton HSM" are trademarks of Craton Inc. The names and logos may be used in unmodified form to refer to the software for factual, descriptive purposes (installation instructions, blog posts, compatibility statements, etc.). They may not be used:

• In the name of a forked distribution, service, or product that could be confused with the upstream project.
• To imply endorsement by Craton Inc. without written permission.
• In a way that violates the BSL-1.1 Additional Use Grant for Enterprise — offering a managed HSM or KMS service using the Enterprise crates is a Competing Use and requires a commercial license.

Trademark questions go to licensing@craton.io.

Contact

• General maintainer questions: engineering@craton.io.
• Security (private): security@craton.io (PGP key publication tracked in security-advisories).
• Commercial licensing, BSL exceptions, trademark: licensing@craton.io.
• Community support / BSL licensing queries: licensing@craton.io (best-effort).