Repository navigation
Make capture verification bounded, historical and explicit about evidence quality #73
Description
Activity
- added
on Sep 24, 2026 Plan (agreed 2026-09-29): this becomes the offline path of a single verification entry point:
dbl verify/client.Verifyin Go, withtools/verify_pcap.pykept consistent.- Result categories: pending / verified / invalid / missing history / unsupported.
- Work caps.
- Evidence bundle, which can include the signed receipt from the server-assisted path (new issue).
Depends on Persist schedule identities and roll TESLA chains without stale-key reuse #71(a).
PR #382, merged as 072ab00. All 16 required jobs passed on the exact candidate and merged main.
The verifier now has server-assisted pre-disclosure checks, signed receipts, mixed disclosed-packet classifications and retained-capture restart coverage alongside the bounded offline reader and versioned fixtures.
This remains open because exported offline schedules and run lookups are still editable claims rather than authenticated metadata. Receipts authenticate their packet digest and verdict, but do not sign every bundled schedule/lookup. The remaining criterion needs authenticated metadata and corresponding tamper checks; docs/verification.md states that boundary explicitly.
- added a commit that references this issue
on Oct 7, 2026 #409 completes the remaining authenticated-metadata gap recorded above. Exported dated lookups now bind the source/query time, retention boundary, run identities/intervals, schedules and disclosure observations; enrolled executor schedule proofs are checked independently with retained certificate pins. Strict offline verification rejects altered/missing signatures, key replacement and replay for another address or time. A real API export remains verifiable after the backend shuts down.
The existing bounded reader, shared versioned vectors, Python outcome comparisons and #382 retained-capture checks remain in place. Candidate counts are checked before certificate work, including unsigned legacy lookups. The verification contract defines result categories, work limits and the portable format for companion implementations.
History authentication, executor-origin authentication and capture-clock trust are separate. Without an independently obtained receiver-to-schedule clock observation, capture time remains untrusted; actual measurement acceptance stays open in #72. A tag attributes packets to a run, not a measurement conclusion. This closes the core verifier work and does not claim browser authentication support.
Merged as a9d865d. All 17 checks passed on the exact candidate (guest source check) and the identical merged main (guest source check).
Problem
The repository already parses PCAP/PCAPNG and checks real tags with the correct debuglet_ids response field. It still obtains candidate runs and schedule material from the current live registry, iterates attacker-supplied epoch/candidate work and relies on capture timestamps without a durable evidence/trust contract.
Proposed change
Provide a bounded verifier and portable evidence bundle that distinguishes lookup, pending disclosure, verified tag, invalid tag, missing history and unsupported formats/modes.
Acceptance criteria
Current evidence
validation and product-contract gap; source inspection only, no new runtime reproduction. Backlog classification is based on source inspection; this issue does not claim a new runtime reproduction.
Dependencies
Related work
These are integration points, not prerequisites for starting this issue.
Priority context
Required before accepting untrusted users or advertising the corresponding protected capability; not a blocker for the trusted local TEST alpha.
Validation must use owned local fixtures on supported Linux environments. Record the implementing merge request and relevant test results before closing this issue.
Imported from GitLab issue 72. Originally opened 2026-09-10. Historical GitLab links may require access to the original project.