reuse-surface/workplans/REUSE-WP-0025-private-source-reader-boundary.md

85 lines
3.7 KiB
Markdown
Raw Normal View History

---
id: REUSE-WP-0025
type: workplan
title: "Bind private source reader to consented metadata URLs"
domain: infotech
repo: reuse-surface
status: blocked
owner: reuse-surface-owner-preparation-worker
created: "2026-10-15"
updated: "2026-10-21"
flavor: implementation
depends_on: [CUST-WP-0081]
state_hub_workstream_id: "23c7bcf5-5f5d-524f-a06e-be5247ae1a98"
---
Prepared in an isolated owner checkout under the user's explicit worker-agent
request. This worker has supervised local preparation scope only; no founder
credential approval, permanent repo-owner authority, deployment, or source-owner
consent is inferred. The custodian integration agent handles hub synchronization
after accepting the proposed owner workitem. No State Hub mutation is performed
from this isolated checkout.
## Independent consumer review
```task
id: REUSE-WP-0025-T01
status: done
priority: high
state_hub_task_id: "1f841e28-fc55-5b12-bb51-bb3291f17d8b"
```
Reviewed consumer INTENT, native authenticated acquisition, public API registration
fields, and stale-cache behavior. The deployed baseline is unsuitable for a new
private reader: registered auth_env/URL can route runtime credentials to arbitrary
hosts; urllib's default redirect handler also forwards Authorization. Review is
`changes_requested`; metadata consent does not authorize reader provisioning.
See docs/assessments/cust81-private-reader/owner-review-r1.md.
## Prepare native boundary and verification helper
```task
id: REUSE-WP-0025-T02
status: done
priority: high
state_hub_task_id: "a9e794f6-a894-52e6-bd93-4781e05c6a55"
```
Patch rejects authenticated cleartext URLs and all redirects, and requires an
operator-controlled exact env-to-URL allowlist before credential lookup. Receipt
helper invokes native fetch directly for all seven consented index/entry pairs,
checks exact hashes and entry schema, and never uses cached fallback. Fake
transport tests and local committed metadata validation are preparation evidence,
not live authenticated fetch receipts.
## Review, publish and verify deployed consumer
```task
id: REUSE-WP-0025-T03
status: wait
priority: high
needs_human: true
intervention_note: "Approved (81c8535a): create reuse-surface-reader Forgejo bot + read:repository PAT into OpenBao/ESO; platform/apps rollout"
blocking_reason: "Execution of approved credential provisioning and platform/apps image rollout"
state_hub_task_id: "789bb918-4848-5bdf-bfd4-8ee42877addb"
decision_id: "81c8535a-e0c3-4cb6-9412-bf5ce7696b3d"
```
Owner review and exact credential/rollout disposition remain pending. Platform/apps
must inventory every existing authenticated dynamic registration without reading
Secret values, migrate approved exact URLs, and deliver a reviewed image containing
the fix plus the exact reader allowlist. Then run helper inside the hub environment
with the owner-provided packets, verify all seven sources fresh, and hand a
sanitized receipt to the custodian for registration and final 70-capability audit.
No new PAT is delivered to the current baseline consumer.
2026-10-21: decision 81c8535a resolved by Bernd — approved (1) the native
boundary fix, (2A) a dedicated Forgejo machine user (e.g. `reuse-surface-reader`)
with read access to exactly the seven consented repos and a `read:repository`
PAT on its own OpenBao KV path, delivered via ESO as
`REUSE_SURFACE_FORGEJO_SOURCE_READ_TOKEN` and allowlisted to the 14 commit-pinned
URLs, and (3) the platform/apps rollout as described above. Remaining: create the
bot user and token (human/operator — agents do not handle the secret value), roll
out, run the helper, hand over the receipt. Follow-up: define how allowlist pins
are refreshed and re-approved when the source repos update their metadata.