Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the mise tool's provenance detection mechanism by enabling the identification of GitHub artifact attestations during the lockfile generation process. This change optimizes the installation workflow for tools utilizing GitHub attestations by pre-recording provenance information, thereby eliminating redundant API calls and mitigating rate limiting issues during subsequent locked installations.

Highlights

• GitHub Attestations Detection: Modified detect_provenance_type to identify GithubAttestations at the mise lock stage, leveraging existing aqua registry metadata.
• Performance Improvement: Enabled mise install --locked to skip redundant GitHub API calls for attestation verification, preventing potential rate limit issues.
• Provenance Priority: Established GithubAttestations as the highest-priority provenance type for detection, followed by SLSA, Cosign, and Minisign.
• New Test Coverage: Introduced an end-to-end test to validate that mise lock correctly records github-attestations provenance and that mise install --locked bypasses unnecessary verification.

Greptile Summary

This PR extends detect_provenance_type() in src/backend/aqua.rs to detect GithubAttestations provenance at lock-time using aqua registry metadata (github_artifact_attestations config), rather than only recording it after successful install-time verification. This means mise lock can now write provenance = "github-attestations" to the lockfile upfront, letting mise install --locked skip the attestation API call entirely (relying on the lockfile checksum for integrity), which resolves the rate-limit failures described in the linked discussion.

Key changes:

• detect_provenance_type() now checks for github_artifact_attestations first, matching the ProvenanceType priority order: GithubAttestations (3) > Slsa (2) > Cosign (1) > Minisign (0). This is a priority flip from the previous behaviour where SLSA was the highest priority detectable at lock-time — any package that supports both mechanisms will now record github-attestations instead of slsa on re-lock.
• The att.enabled != Some(false) guard is consistent with the install-time verify_github_artifact_attestations logic, which treats an absent enabled field as enabled.
• An e2e test exercises the full lock → install flow with jq 1.8.1, asserting the lockfile records the expected provenance and that the subsequent --locked install doesn't emit the attestation-verification progress message.

Confidence Score: 5/5

Safe to merge — the logic change is small, correct, and consistent with existing provenance-detection patterns.

No P0 or P1 issues found. The core change correctly mirrors the SLSA/Cosign/Minisign detection approach, the enabled-field guard is consistent with install-time verification, and the priority ordering matches the existing ProvenanceType ordinal values. The only remaining concern (fragile shell quoting in the e2e test) was already flagged in a prior review thread and does not affect production correctness.

e2e/lockfile/test_lockfile_github_attestations_provenance — the assert_not_contains shell-quoting issue noted in a prior review comment is still present.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant User
    participant mise
    participant AquaRegistry
    participant GitHubAPI

    Note over User,GitHubAPI: mise lock (before this PR)
    User->>mise: mise lock
    mise->>AquaRegistry: fetch package metadata
    AquaRegistry-->>mise: github_artifact_attestations config
    mise->>mise: detect_provenance_type() → None (skipped)
    mise-->>User: lockfile with checksum only

    Note over User,GitHubAPI: mise install --locked (before this PR)
    User->>mise: mise install --locked
    mise->>mise: has_lockfile_integrity = false (no provenance)
    mise->>GitHubAPI: verify_github_artifact_attestations()
    GitHubAPI-->>mise: rate limit error ❌

    Note over User,GitHubAPI: mise lock (after this PR)
    User->>mise: mise lock
    mise->>AquaRegistry: fetch package metadata
    AquaRegistry-->>mise: github_artifact_attestations config
    mise->>mise: detect_provenance_type() → GithubAttestations ✓
    mise-->>User: lockfile with checksum + provenance="github-attestations"

    Note over User,GitHubAPI: mise install --locked (after this PR)
    User->>mise: mise install --locked
    mise->>mise: has_lockfile_integrity = true (checksum + provenance)
    mise->>mise: ensure_provenance_setting_enabled()
    mise-->>User: install complete (no GitHub API call) ✓

_{Reviews (4): Last reviewed commit: "Merge branch 'main' into gh-provenance" | Re-trigger Greptile}

@jdx I know you're very busy these days. Please let me know if there's any way in which I can make the PR review easier or help to hopefully get this fix evaluated & merged soon. This one is a really important one that seems to affect a bunch of users using locked mode with artifacts downloaded from GH :)

I'm holding off on merging this until the underlying security issue is resolved.

The PR itself doesn't introduce the problem — it follows the same pattern already used by SLSA, cosign, and minisign. But it extends the gap to GitHub attestations, which were previously verified at install-time.

The core issue: mise lock records provenance based purely on aqua registry metadata (detection), but no actual cryptographic verification happens. Then mise install sees the lockfile has both a checksum and provenance entry and skips verify_provenance() entirely (src/backend/aqua.rs:997-1011). This means provenance is never actually verified in the mise lock → mise install flow — for any provenance type, not just GitHub attestations.

Provenance is supposed to verify that an artifact was built by a trusted CI pipeline, not just that it hasn't been tampered with since lock-time. If the registry or download source is compromised at lock-time, both the checksum and the unverified provenance field get written to the lockfile without any validation.

This needs to be fixed before we add more provenance types to the lock-time detection path. Possible approaches:

• mise lock actually verifies provenance (at least for the current platform)
• mise install --locked still verifies provenance even when the lockfile has a provenance entry
• Provenance recorded at lock-time is marked as "unverified" and verified on first install

Under paranoid mode, we could modify this behavior to:

• mise install always verifies provenance at install-time regardless of what the lockfile contains, rather than trusting the lockfile's provenance field as proof of prior verification
• mise lock downloads and verifies provenance for all platforms, not just the current one

This comment was generated by Claude Code.

• mise lock actually verifies provenance (at least for the current platform)

I’m in favor of that approach.

If we adopt it, then during mise i --locked we could reasonably rely on the checksums alone, right?

The main motivation for skipping provenance checks at install time is to avoid repeatedly hitting GitHub API endpoints.
During the locking phase, we can assume the user has a GitHub API token configured (or is prepared to deal with rate limits), since updating the lockfile is an intentional action.

However, for consumers of the lockfile – in my case, this would be our developers and end users – verifying the checksum should be sufficient, without requiring additional provenance checks.

Is there any way in which I can help you resolve this issue, or at least test if and how certain approaches would work in our concrete dev & CI setup?

Thank you,
Richard