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.
This commit is contained in:
40
tasks/architecture/storage/specify-key-rotation-protocol.md
Normal file
40
tasks/architecture/storage/specify-key-rotation-protocol.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
id: specify-key-rotation-protocol
|
||||
name: Specify secret key rotation protocol and multi-key format
|
||||
status: completed
|
||||
depends_on: []
|
||||
scope: narrow
|
||||
risk: critical
|
||||
impact: component
|
||||
level: implementation
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Lazy re-encryption in `services.md:94-97` is insufficiently specified for a security-critical operation:
|
||||
1. `HUB_ENCRYPTION_KEY` (singular env var) — how are old and new keys stored simultaneously during rotation?
|
||||
2. If process crashes between decrypt and re-encrypt-update, is the secret left in the old key version?
|
||||
3. What happens if a secret with `keyVersion=1` is accessed after the old key is removed? Permanent data loss.
|
||||
4. 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
|
||||
Reference in New Issue
Block a user