[Task] Decide: Should secret encryption remain a kernel primitive or become an access-owned capability? #56

Closed
opened 2026-07-06 11:34:52 +02:00 by zemion · 1 comment
Owner

Imported from the GovOPlaN access extraction plan open decisions.

  • Source: /mnt/DATA/git/govoplan-core/docs/ACCESS_EXTRACTION_PLAN.md
  • Line: 357
  • Section: Open Decisions
  • Source status: decision needed

Imported backlog item:

- [ ] Should secret encryption remain a kernel primitive or become an access-owned capability?
<!-- codex-backlog-fingerprint:facc04399b3753d912eef2c8 --> Imported from the GovOPlaN access extraction plan open decisions. - Source: `/mnt/DATA/git/govoplan-core/docs/ACCESS_EXTRACTION_PLAN.md` - Line: `357` - Section: `Open Decisions` - Source status: `decision needed` Imported backlog item: ```markdown - [ ] Should secret encryption remain a kernel primitive or become an access-owned capability? ```
zemion added this to the Access Extraction milestone 2026-07-06 12:48:47 +02:00
zemion added the
status
needs-info
label 2026-07-08 02:59:57 +02:00
Author
Owner

Codex State: decision recorded 2026-07-09

Decision: secret encryption remains a kernel primitive, not an access-owned capability.

Rationale: encrypted secrets are already used outside access, notably mail server credentials and file connector credentials. Moving encryption into access would force modules that manage credentials to depend on access internals for a generic security primitive.

Current state: govoplan_core.security.secrets provides encrypt_secret/decrypt_secret and is consumed by govoplan-mail and govoplan-files. If the optional secret-provider capability grows, it should become a generic core secrets contract rather than live under access ownership.

Effects: file connector credential work and mail credential work should keep using the kernel primitive; #62/#63 should not try to move encryption into access.

## Codex State: decision recorded 2026-07-09 Decision: secret encryption remains a kernel primitive, not an access-owned capability. Rationale: encrypted secrets are already used outside access, notably mail server credentials and file connector credentials. Moving encryption into access would force modules that manage credentials to depend on access internals for a generic security primitive. Current state: govoplan_core.security.secrets provides encrypt_secret/decrypt_secret and is consumed by govoplan-mail and govoplan-files. If the optional secret-provider capability grows, it should become a generic core secrets contract rather than live under access ownership. Effects: file connector credential work and mail credential work should keep using the kernel primitive; #62/#63 should not try to move encryption into access.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: add-ideas/govoplan-core#56
No description provided.