| name | kms-changelog |
| description | Create or update the branch CHANGELOG entry. Use when writing a changelog entry for this branch. |
KMS Changelog Entry
Create or update the branch-specific CHANGELOG entry for this repository.
Important Notes
- Root
CHANGELOG.md is auto-generated by git-cliff — NEVER edit it manually.
- Branch changelogs live in
CHANGELOG/<branch-name>.md (replace / with _).
- Example: branch
feature/my-feature → CHANGELOG/feature_my-feature.md
Step 1 — Determine the Branch
git branch --show-current
Never guess the branch name. Always run this command.
The changelog file path is: CHANGELOG/<branch-name-with-slashes-replaced-by-underscores>.md
Example: branch fix/kmip-auth-bypass → CHANGELOG/fix_kmip-auth-bypass.md
Step 2 — Assess Whether an Entry Is Warranted
Write a changelog entry only when the change is:
- A new feature (user-visible or operator-visible)
- A bug fix
- A security hardening or vulnerability fix
- A behavioral change (default behavior, error messages, CLI output)
- A breaking change (API signatures, CLI flags, config keys, supported algorithms)
- A significant refactor that materially affects operators or contributors
Skip for: routine internal implementation, formatting, minor refactors, test-only changes that don't affect observable behavior, CI pipeline adjustments.
If unsure, ask the user: "Does this change any of: public API signatures, CLI flags/output, config file keys, default behavior, supported algorithms, or error messages visible to operators?"
Step 3 — Gather Information
Ask the user (or infer from git diff and context):
- What changed? (one-sentence summary)
- Which category: Features / Bug Fixes / Security / Refactor / Build / CI / Documentation / Testing
- Which component:
kmip, api, cli, ui, crypto, db, hsm, config, wasm, docs, nix, ci
- Is there a related GitHub PR or issue number? (optional)
- Are there any linked issues to close? (optional)
Step 4 — Write the Entry
Create or append to CHANGELOG/<branch>.md using this structure:
## Features
### KMIP / Crypto
- Add `ReKey` operation with AES-256-GCM support for symmetric key rotation ([#42](https://github.com/Cosmian/kms/issues/42))
### CLI
- Add `ckms keys rekey` subcommand with `--uid` and `--wrapping-key-uid` flags
## Bug Fixes
### API
- Return HTTP 403 (not 500) when key access is denied in `Get` operation ([#38](https://github.com/Cosmian/kms/issues/38))
## Security
- Enforce access control check in `Wrap` operation before returning wrapped key material
## Build
- Upgrade OpenSSL from 3.5.0 to 3.6.0 (FIPS provider updated)
---
Closes #38
Closes #42
Section names: Features, Bug Fixes, Security, Refactor, Documentation, Testing, CI, Build
Sub-group by component when multiple entries share the same area (e.g. multiple KMIP changes under ### KMIP).
Step 5 — Create the File if Needed
If CHANGELOG/<branch>.md does not exist yet:
ls CHANGELOG/
Create it with just the new entry. Do not copy content from other CHANGELOG files.
Step 6 — Breaking Changes
If the change introduces a breaking change, add a ## Breaking Changes section at the top with a migration guide:
## Breaking Changes
### CLI
- `--sqlite-path` flag renamed to `--sqlite-data-path`. Update startup scripts and `kms.toml`:
```toml
# Old
sqlite-path = "/data/kms"
# New
sqlite-data-path = "/data/kms"
## PR/Issue Link Format
- PR link: `([#N](https://github.com/Cosmian/kms/pull/N))`
- Issue link: `([#N](https://github.com/Cosmian/kms/issues/N))`
- Auto-close syntax at end of file: `Closes #N`