fix(release): verify visual-hashing against its own repository

[paudley]

just verify-release failed the 1.0.0-rc.1 candidate on four checks — all one root cause: the verifier still assumed visual-hashing is published from this monorepo.

FAIL: crates.io: SLSA provenance visual-hashing-0.1.3.crate
      HTTP 404 .../repos/Blackcat-Informatics/gmeow-gts/attestations/sha256:...
FAIL: crates.io: SPDX SBOM predicate visual-hashing-0.1.3.crate
      HTTP 404 (same)
FAIL: crates.io visual-hashing: repository metadata
      expected .../gmeow-gts, got .../visual-hashing

visual-hashing moved to Blackcat-Informatics/visual-hashing in 0.9.6 and publishes with its own crates.io Trusted Publisher — so its attestations live in that repository's store, and its crates.io repository field correctly names that repository. The verifier queried this one for both.

The failure mode is the interesting part. A bare HTTP 404 from the attestation API reads exactly like a missing attestation, so the honest reading of the old output was "visual-hashing shipped without provenance" — alarming, and wrong. The attestations were there all along, in the right place; nothing was looking for them there.

Fix

The attestation plan now carries the attesting repository per artifact rather than assuming one repository for the whole release, and expected_repo_urls takes the publishing repository for the crate under test. Everything except visual-hashing keeps the previous behaviour by default.

This could only surface at release-verification time — the last section of the checklist — and only for a release family depending on a crate published elsewhere.

Verified

python3 scripts/verify_release.py --self-test        OK
just verify-release 1.0.0-rc.1 0.1.3                 103 PASS / 0 FAIL (live registries)

Also gitignores dist/release-verification/, which is release evidence uploaded as a workflow artifact rather than repository content — same treatment as the dist/v*/ candidate bundles.

Summary by CodeRabbit

• New Features

  • Release verification now supports the visual-hashing package being published from its standalone repository.
  • Added configuration for specifying the visual-hashing source repository during verification.

• Chores

  • Added ignore rules for release verification artifacts and downloaded registry files.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Team

Run ID: 7257e803-6244-4c94-90df-310ecd9770ea

📥 Commits

Reviewing files that changed from the base of the PR and between b9746bd and 77116fb.

📒 Files selected for processing (2)

• .gitignore
• scripts/verify_release.py

Included review availability: 0 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 1 review per hour.

---

📝 Walkthrough

Walkthrough

Release verification now supports visual-hashing artifacts published from a standalone repository. Repository-specific metadata and GitHub attestations are validated through the new --visual-hashing-repo option.

Changes

Release verification

Layer / File(s)	Summary
Repository-specific crate configuration scripts/verify_release.py	Adds --visual-hashing-repo, supports crate-specific source repositories, and retains the repository for visual-hashing artifacts.
Repository-aware attestation verification scripts/verify_release.py, .gitignore	Associates each artifact with its repository during attestation planning and verification. Ignores release verification output under dist/release-verification/.

Estimated code review effort: 4 (Complex) | ~45 minutes

Merge Risk: ⚪ Minimal · up to 77116

Release verification now uses visual-hashing’s standalone repository for crate metadata and GitHub attestation checks. No concrete merge-blocking risk remains.

Sequence Diagram(s)

sequenceDiagram
  participant ReleaseVerifier
  participant CrateVerifier
  participant AttestationPlan
  participant GitHub
  ReleaseVerifier->>CrateVerifier: validate crate using source repository
  CrateVerifier->>AttestationPlan: retain artifact repository
  AttestationPlan->>GitHub: request repository-specific attestations
  GitHub-->>ReleaseVerifier: return provenance and SPDX SBOM results

Loading

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 28.57% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 7 functions across 1 files. (1 skipped: 1…	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the primary change: release verification now checks visual-hashing against its own repository.
Description check	✅ Passed	The description clearly explains what changed, why it changed, the affected release-verification behavior, and the successful validation results. It does not use the template headings or explicitly id…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

Docstring coverage is 28.57% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 7 functions across 1 files. (1 skipped: 1 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/verify-release-visual-hashing-repo

---

_{Comment @coderabbitai help to get the list of available commands.}