hub/tasks/architecture/storage/specify-key-rotation-protocol.md at main

alkdev/hub

Files

glm-5.1 2b63cda1c7 Setup repo: migrate architecture specs, code stubs, and tasks from alkhub_ts

Copy architecture docs, ADRs, storage domain specs, research, reviews,
and 56 storage architecture tasks from the alkhub_ts monorepo. Adapt for
standalone @alkdev/hub repo structure (src/ not packages/hub/).

Sanitize all sensitive information:
- Replace private IPs (10.0.0.1) with localhost defaults
- Remove internal server hostnames (dev1, ns528096)
- Replace /workspace/ private paths with npm package references
- Remove hardcoded credentials from examples
- Rewrite infrastructure.md without private network details

Add Deno project scaffolding: deno.json (pinned deps), .gitignore,
AGENTS.md, entry point. Migrate existing code stubs (crypto, config
types, logger) with updated import paths.

2026-05-25 10:56:32 +00:00

1.6 KiB

Raw Permalink Blame History

id, name, status, depends_on, scope, risk, impact, level

name

status

depends_on

scope

risk

impact

level

specify-key-rotation-protocol

Specify secret key rotation protocol and multi-key format

completed

narrow

critical

component

implementation

Description

Lazy re-encryption in services.md:94-97 is insufficiently specified for a security-critical operation:

HUB_ENCRYPTION_KEY (singular env var) — how are old and new keys stored simultaneously during rotation?
If process crashes between decrypt and re-encrypt-update, is the secret left in the old key version?
What happens if a secret with keyVersion=1 is accessed after the old key is removed? Permanent data loss.
No background sweep — old-key-version secrets persist indefinitely. If old key is compromised, those secrets remain vulnerable.

Acceptance Criteria

services.md specifies multi-key storage format: e.g., HUB_ENCRYPTION_KEYS=v1:base64key,v2:base64key or a key file
The re-encryption transaction is documented: decrypt → encrypt → UPDATE in a single DB transaction, with crash-safety note
A warning about the vulnerability window is added: old-key secrets not yet re-encrypted are at risk if old key is compromised
Decision documented: whether a background re-encryption sweep is required or deferred
Error handling for missing key version is documented: log error, skip re-encryption, alert operator

References

docs/reviews/storage-architecture-review-2026-04-21.md#C11
docs/architecture/storage/services.md:94-97
docs/decisions/ADR-008

Notes

To be filled by implementation agent

Summary

To be filled on completion

1.6 KiB Raw Permalink Blame History