Reuse local asset verification during delivery uploads

This commit is contained in:
2026-10-10 15:17:18 +00:00
parent c0a3f55f12
commit 80d88a0352
7 changed files with 133 additions and 11 deletions

View File

@@ -1,6 +1,6 @@
# Remediation: module release implementation review
Status: open; issues 1–12 are complete, and issues 13–15 require remediation.
Status: open; issues 1–13 are complete, and issues 14–15 require remediation.
The initial review examined `90559fe`, compared with planning baseline `dbfae9e`.
The follow-up repository audit examined `6b0b8ce`, including those corrections.
@@ -462,7 +462,17 @@ differences, ordinary aliases, cycles, and outside-checkout failures.
## Issue 13: Reuse local asset verification through the complete delivery path (P2)
Status: open. Category: incomplete verification ownership and redundant I/O.
Status: complete. Category: incomplete verification ownership and redundant I/O.
**Completion:** Assembled delivery reuses its preflight verification through the
internal upload path; standalone internal uploads retain local verification.
A Linux filesystem-event regression observes one verification read and one
upload read across public delivery and validates uploaded contents. It failed
with three reads before the correction. Delivery/Gitea suites pass offline,
including tampering, caller ownership, matching attachments, and partial retries.
The complete-delivery benchmark now supplies current module identity. Its 32 MiB
fresh-upload case measured about 352 ms before and 254 ms afterward on this host;
these illustrative measurements introduce no timing gate.
**Evidence:** [Delivery](../../internal/delivery/delivery.go) calls
`VerifyLocalAssets` before hosted requests. After release and attachment