[Feature] Add versioned content-encryption envelopes and E2EE integration contracts #3

Closed
opened 2026-07-30 17:34:18 +02:00 by zemion · 2 comments
Owner

Provide reusable cryptographic envelopes for modules such as Files, Postbox, Campaign, Calendar, and connector credentials without coupling those modules to a concrete vault/provider.

Acceptance criteria

  • Ciphertext envelopes carry bounded algorithm, key reference, version, integrity, tenant/scope, and migration metadata.
  • Module contracts distinguish server-readable encryption from E2EE and declare feature degradation explicitly.
  • Re-encryption/rotation is resumable, idempotent, observable, and leaves no mixed state without provenance.
  • Ownership transfer never implies key transfer; key hand-over/re-encryption is a separately authorized workflow.
  • Optional-module absence fails closed for encrypted content while unencrypted module combinations continue to work.
  • At least Files and Postbox integration fixtures validate the boundary before production rollout.
Provide reusable cryptographic envelopes for modules such as Files, Postbox, Campaign, Calendar, and connector credentials without coupling those modules to a concrete vault/provider. ## Acceptance criteria - Ciphertext envelopes carry bounded algorithm, key reference, version, integrity, tenant/scope, and migration metadata. - Module contracts distinguish server-readable encryption from E2EE and declare feature degradation explicitly. - Re-encryption/rotation is resumable, idempotent, observable, and leaves no mixed state without provenance. - Ownership transfer never implies key transfer; key hand-over/re-encryption is a separately authorized workflow. - Optional-module absence fails closed for encrypted content while unencrypted module combinations continue to work. - At least Files and Postbox integration fixtures validate the boundary before production rollout.
Author
Owner

Codex State: progress

Summary

  • Implemented bounded versioned protection envelopes, exact target-envelope migration state, idempotent/reconcilable outcomes, fail-closed disable preflight, and Files/Postbox boundary fixtures.
  • This remains open for concrete Files/Postbox/Campaign/Calendar adapters, real cryptographic rewrap/re-encryption workers, client E2EE custody flows, and target-environment migration/recovery evidence.

Changed Files

  • src/govoplan_encryption/backend/service.py
  • docs/ENCRYPTION_BOUNDARY.md
  • tests/test_encryption.py

Verification

  • Envelope, migration, tenant-isolation, disable, and Files/Postbox fixture tests passed in GovOPlaN/govoplan-encryption@858c41d.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Implemented bounded versioned protection envelopes, exact target-envelope migration state, idempotent/reconcilable outcomes, fail-closed disable preflight, and Files/Postbox boundary fixtures. - This remains open for concrete Files/Postbox/Campaign/Calendar adapters, real cryptographic rewrap/re-encryption workers, client E2EE custody flows, and target-environment migration/recovery evidence. ### Changed Files - `src/govoplan_encryption/backend/service.py` - `docs/ENCRYPTION_BOUNDARY.md` - `tests/test_encryption.py` ### Verification - `Envelope, migration, tenant-isolation, disable, and Files/Postbox fixture tests passed in GovOPlaN/govoplan-encryption@858c41d.` Suggested status label: `status/in-progress`
zemion added
status
in-progress
and removed
status
ready
labels 2026-08-01 21:06:08 +02:00
Author
Owner

Codex State: done

Summary

  • Completed bounded versioned content envelopes plus owner-facing protect/open, same-provider rewrap, and resumable two-phase re-encryption contracts.
  • Files and Postbox now resolve Encryption only through optional Core capabilities, persist ciphertext and opaque envelope references, continue plaintext operation without Encryption, and fail closed when encrypted content cannot be opened.
  • Server-readable, tenant-held, and end-to-end profile kinds remain explicit. The shipped implementation is server-readable only and makes no E2EE claim.

Changed Files

  • src/govoplan_encryption/backend/service.py
  • src/govoplan_files/backend/storage/content_protection.py
  • src/govoplan_postbox/backend/content_protection.py
  • docs/ENCRYPTION_BOUNDARY.md

Verification

  • Encryption migration, replay, outcome-unknown reconciliation, and two-phase owner confirmation tests passed.
  • Files: 95 tests passed; Postbox: 36 tests passed.
  • Pushed as Encryption 42f35f8, Files 359c4e9, Postbox 8f8d259.
## Codex State: done ### Summary - Completed bounded versioned content envelopes plus owner-facing protect/open, same-provider rewrap, and resumable two-phase re-encryption contracts. - Files and Postbox now resolve Encryption only through optional Core capabilities, persist ciphertext and opaque envelope references, continue plaintext operation without Encryption, and fail closed when encrypted content cannot be opened. - Server-readable, tenant-held, and end-to-end profile kinds remain explicit. The shipped implementation is server-readable only and makes no E2EE claim. ### Changed Files - `src/govoplan_encryption/backend/service.py` - `src/govoplan_files/backend/storage/content_protection.py` - `src/govoplan_postbox/backend/content_protection.py` - `docs/ENCRYPTION_BOUNDARY.md` ### Verification - `Encryption migration, replay, outcome-unknown reconciliation, and two-phase owner confirmation tests passed.` - `Files: 95 tests passed; Postbox: 36 tests passed.` - `Pushed as Encryption 42f35f8, Files 359c4e9, Postbox 8f8d259.`
zemion removed the codex/ready
status
in-progress
labels 2026-08-02 03:46:53 +02:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-encryption#3