Skip to content

Troubleshooting UniRTM Provenance Verification Issues ​

Problem ​

When running make sync-lock or unirtm lock, you may encounter an error like:

unirtm ERROR github:astral-sh/ruff@0.15.9 has no provenance verification on macos-x64,
but github:astral-sh/ruff@0.15.8 had github-attestations. This could indicate a supply
chain attack. Verify the release is authentic before proceeding.

This error occurs even when the GitHub release page clearly shows that attestations ARE present.

Root Cause ​

The issue is caused by stale cached metadata in unirtm's cache directory. When unirtm checks for provenance verification:

  1. It caches the verification status of previous versions (e.g., ruff 0.15.8 had attestations)
  2. When a new version is released (e.g., ruff 0.15.9), unirtm may fail to fetch fresh attestation data
  3. The cached metadata becomes outdated, causing false positives for supply chain attacks

Solution ​

Clear the unirtm cache before synchronizing the lockfile. This has been implemented in scripts/sync-lock.sh:

sh
# Clear unirtm cache to avoid stale provenance verification data
log_debug "Clearing unirtm cache to refresh provenance verification data..."
unirtm cache clear >/dev/null 2>&1 || true

The cache clear operation:

  • Runs silently (>/dev/null 2>&1)
  • Never fails the script (|| true)
  • Ensures fresh provenance verification data is fetched

Manual Verification ​

To manually verify that attestations exist for a release:

  1. Visit the GitHub release page (e.g., https://github.com/astral-sh/ruff/releases/tag/0.15.9)
  2. Look for the "Verifying GitHub Artifact Attestations" section
  3. Verify using GitHub CLI:
sh
gh attestation verify <file-path> --repo astral-sh/ruff

Prevention ​

The fix is now automated in the CI/CD pipeline:

  • The "🔄 Sync Dependabot Config" workflow runs make sync-lock
  • scripts/sync-lock.sh automatically clears the cache before locking
  • This prevents stale provenance verification errors

References ​

Released under the MIT License.