[Feature] Provide explicitly governed Windows-compatible encrypted Campaign ZIP output #76

Open
opened 2026-07-20 14:44:02 +02:00 by zemion · 1 comment
Owner

Problem

Some recipients require encrypted ZIP archives compatible with Windows built-in tooling. The local WIP includes legacy ZipCrypto output, but legacy encryption is materially weaker and must never be selected or downgraded silently.

Accepted Policy Model

Legacy Windows-compatible ZipCrypto is an explicitly governed policy capability, not merely a per-campaign format toggle. Add campaign.archiveEncryption to the established system → tenant → owner user/group → campaign provenance chain. Effective allowed methods are an intersection: the baseline is AES only, and a child scope cannot loosen a parent restriction.

Acceptance Criteria

  • Effective allowed_password_encryption_methods defaults to [aes], controls selection, and exposes its complete policy source/provenance.
  • Policy writes require admin:policies:write; selecting legacy ZipCrypto additionally requires a dedicated campaigns:archive:use-legacy-zipcrypto permission.
  • UI/API name it Legacy ZipCrypto — Windows-compatible, weak encryption; when allowed, selection requires explicit acknowledgement and reason.
  • Strong AES remains the default. When legacy mode is disallowed, the UI shows the effective reason/source rather than hiding an API-only denial.
  • API validation/build fail closed if policy is unavailable or ZipCrypto is disallowed. Queue/send reject a stale build if policy became more restrictive.
  • No AES-to-ZipCrypto fallback or downgrade occurs after any error.
  • Password/key delivery is separated from the archive and follows an explicit channel policy.
  • Frozen evidence records format, implementation/package version, policy hash/source path, acknowledging actor/reason/time, campaign/build/version, and archive/member hashes—never passwords.
  • Policy or method changes invalidate build/review evidence. Policy writes, acknowledgements, denied attempts, and legacy builds are audited.
  • Temporary plaintext/archive material is bounded and cleaned after success/failure.
  • Tests cover default denial, scope precedence, authorization/API bypass, post-build policy changes, provenance, corruption, wrong passwords, large files, Windows extraction, AES clients, cleanup, and absence of downgrade.

Audited Local State (2026-07-20)

AES defaults and functional ZipCrypto code/tests exist in mixed local WIP, but ZipCrypto is directly selectable and backend validation has no policy gate. Isolate the policy contract and security-sensitive implementation into reviewable commits before integration.

## Problem Some recipients require encrypted ZIP archives compatible with Windows built-in tooling. The local WIP includes legacy ZipCrypto output, but legacy encryption is materially weaker and must never be selected or downgraded silently. ## Accepted Policy Model Legacy Windows-compatible ZipCrypto is an explicitly governed policy capability, not merely a per-campaign format toggle. Add `campaign.archiveEncryption` to the established system → tenant → owner user/group → campaign provenance chain. Effective allowed methods are an intersection: the baseline is AES only, and a child scope cannot loosen a parent restriction. ## Acceptance Criteria - [ ] Effective `allowed_password_encryption_methods` defaults to `[aes]`, controls selection, and exposes its complete policy source/provenance. - [ ] Policy writes require `admin:policies:write`; selecting legacy ZipCrypto additionally requires a dedicated `campaigns:archive:use-legacy-zipcrypto` permission. - [ ] UI/API name it `Legacy ZipCrypto — Windows-compatible, weak encryption`; when allowed, selection requires explicit acknowledgement and reason. - [ ] Strong AES remains the default. When legacy mode is disallowed, the UI shows the effective reason/source rather than hiding an API-only denial. - [ ] API validation/build fail closed if policy is unavailable or ZipCrypto is disallowed. Queue/send reject a stale build if policy became more restrictive. - [ ] No AES-to-ZipCrypto fallback or downgrade occurs after any error. - [ ] Password/key delivery is separated from the archive and follows an explicit channel policy. - [ ] Frozen evidence records format, implementation/package version, policy hash/source path, acknowledging actor/reason/time, campaign/build/version, and archive/member hashes—never passwords. - [ ] Policy or method changes invalidate build/review evidence. Policy writes, acknowledgements, denied attempts, and legacy builds are audited. - [ ] Temporary plaintext/archive material is bounded and cleaned after success/failure. - [ ] Tests cover default denial, scope precedence, authorization/API bypass, post-build policy changes, provenance, corruption, wrong passwords, large files, Windows extraction, AES clients, cleanup, and absence of downgrade. ## Audited Local State (2026-07-20) AES defaults and functional ZipCrypto code/tests exist in mixed local WIP, but ZipCrypto is directly selectable and backend validation has no policy gate. Isolate the policy contract and security-sensitive implementation into reviewable commits before integration.
Author
Owner

Product decision (2026-07-20): Windows-compatible legacy encryption is also a policy. The issue now records a default-deny effective-policy model and is ready for isolation/review; it must not ship as an ungoverned format toggle.

Product decision (2026-07-20): Windows-compatible legacy encryption is also a policy. The issue now records a default-deny effective-policy model and is ready for isolation/review; it must not ship as an ungoverned format toggle.
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-campaign#76
No description provided.