Story: Security module
Table of Contents
This page documents a story in Sprint 09. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
Goal
Consolidate shared security primitives into a dedicated
ores.security component so future audits look at one component,
not three.
Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 09 |
| Now | Completed 2026-01-13. |
| Waiting on | None. |
| Next | None. |
| Last touched | 2026-01-13 |
Acceptance
ores.securitycomponent scaffolded.- Password and encryption code migrated from
ores.iam+ores.connections. - OpenSSL contexts managed via RAII.
- Downstream components linked through the new library.
Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Create ores.security module | DONE | 2026-05-19 | 2026-01-13 | Extract shared security primitives from ores.iam and ores.connections into a new ores.security component; rename password_manager -> password_hasher, encryption_service -> encryption; apply RAII to OpenSSL cipher contexts. |
Decisions
- RAII for OpenSSL
std::unique_ptrwith a customEVP_CIPHER_CTX_freedeleter eliminates the long error-path cleanup that was the source of leak reports.- Clearer naming
password_hasherandencryptionname what they do;password_managerandencryption_servicewere vague.
Out of scope
- Key-rotation tooling (planned separately).
- Hardware security module integration.
See also
- Connection management — primary consumer alongside IAM.