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

Closed
opened 2026-07-20 14:44:02 +02:00 by zemion · 3 comments
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.
Author
Owner

Codex State: ready

Summary

  • Implemented policy-governed Windows-compatible encrypted Campaign ZIP output with capability probing, strength policy, recipient/key separation, evidence, and administrator configuration.
  • Local commits: Campaign 75e8f86, Policy be5e3a7, Core 79629c5.

Verification

  • tools/checks/check-focused.sh: passed the integrated backend, manifest, UI-contract, 59-permutation build, and Playwright conformance gate.

Next / Blocked

  • Push the local commits, run remote CI, then close the issue after integration.

Suggested status label: status/ready

## Codex State: ready ### Summary - Implemented policy-governed Windows-compatible encrypted Campaign ZIP output with capability probing, strength policy, recipient/key separation, evidence, and administrator configuration. - Local commits: Campaign 75e8f86, Policy be5e3a7, Core 79629c5. ### Verification - `tools/checks/check-focused.sh: passed the integrated backend, manifest, UI-contract, 59-permutation build, and Playwright conformance gate.` ### Next / Blocked - Push the local commits, run remote CI, then close the issue after integration. Suggested status label: `status/ready`
Author
Owner

Published and verified on remote main: Campaign 75e8f86, Policy be5e3a7, Core 79629c5. The repository has no configured commit-status contexts/workflow files; the recorded complete focused workspace gate is the integration evidence. Acceptance criteria are satisfied, so this issue is being closed.

Published and verified on remote `main`: Campaign 75e8f86, Policy be5e3a7, Core 79629c5. The repository has no configured commit-status contexts/workflow files; the recorded complete focused workspace gate is the integration evidence. Acceptance criteria are satisfied, so this issue is being closed.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-campaign#76