ReviewOS

pantry-pm/pantry

feat(registry): safely rescan and release quarantined false positives

#226
Closed chris opened this 2 months ago ·
2 months ago

Problem

Publish-time and retained-artifact malware blocks are correctly fail-closed and durable, but the current incident runbook's “update definitions and rescan” step cannot be completed after quarantine: installable metadata and objects are deliberately removed, and the tombstone prevents pkgx fallback from recreating them.

The Vault false-positive reproduction in #225 makes this an operational requirement, not a hypothetical edge case.

Outcome

Add a digest-bound, operator-only quarantine review workflow that scans the private quarantined object with current definitions and:

  • keeps it quarantined on any blocked/error/review result;
  • restores installable objects and clean attestations only after a fresh clean verdict;
  • atomically publishes metadata last;
  • preserves the original quarantine bytes and evidence for audit;
  • removes only the exact reviewed tombstone;
  • works with isolated external ClamAV runners in production;
  • never depends on the legacy migration cutoff and never accepts a digest mismatch.

Acceptance criteria

  • Private tombstones retain the quarantine object identity needed for future reviews.
  • Existing tombstones created before that field can be reviewed with an explicit validated filename.
  • Prepare/attest APIs are operator-only and bind domain, version, digest, size, object identity, and quarantine key.
  • A blocked rescan updates review evidence and exposes zero installable bytes.
  • A clean rescan copies bytes and sidecars first, writes metadata last, and removes only the matching tombstone.
  • A stale or changed quarantine object is rejected.
  • The hosted workflow and CLI provide a manual, reusable review path.
  • Tests and the incident runbook cover release and non-release behavior.

Refs #220

Refs #224

Refs #225

8 days ago

Implementation is on main in small conventional commits:

  • 56f2088ee — operator-only, identity-bound quarantine prepare/attest APIs
  • fdadeee89 — blocked/clean/legacy/stale/auth test coverage
  • 9845c7fd1 — reusable hosted ClamAV review workflow and CLI
  • 90632ca0e — safe recovery runbook and API docs
  • d28bdb9bc — shared cross-version quarantine-object handling

Verification so far: 29 focused registry tests pass, registry typecheck passes, 13 workflow/backfill tests pass, the CLI bundles, and workflow YAML parses. Deployment 30522931800 succeeded; final shared-object fix deployment is in progress.

A production blocked-review proof is queued as 30523065291 behind the authoritative catalog reconciliation. It will rescan the exact private Vault digest with current definitions, must remain quarantined, and must write no installable metadata. Refs #220, #224, and #225.

8 days ago

Production acceptance proof is complete.

  • 335014e84 restores a lost metadata tombstone only from exact digest/filename-bound private .scan.json evidence, and prevents an older clean review from overriding another active quarantine on the same platform.
  • f295058ab authorizes binary downloads against exact active metadata, denies overlapping quarantine tombstones, and emits no presigned capability for private/unindexed objects.
  • Deployments 30586887989 and 30587350913 succeeded.
  • Exact review 30586973294 scanned Vault 2.0.2 darwin-arm64 digest adcf7d117296e3fe50a99889e9a052579f450c50d66bbbafddc4217e644a88de with ClamAV 1.5.3/28077, detected Macos.Infostealer.Amos-10056367-1, returned still-quarantined, and intentionally exited nonzero for operator attention.
  • Raw private metadata now contains the exact restored tombstone with current scan/review timestamps and size 82,905,496; an immutable .review-2026-07-30T22-24-49-135Z.json record was written beside the original quarantine object and sidecar.
  • Public metadata contains no private tombstones or affected Darwin platforms. All four affected Vault public tarball routes return 404, zero redirect, and no artifact bytes.
  • Verification: 34 publisher tests (127 assertions), 63 proxy/e2e tests (199 assertions), registry typecheck, and focused lint.

All acceptance criteria are satisfied. Refs #220, #224, and #225.

Sign in to comment on this issue.