fix(install): add locked_verify_provenance setting and detect github attestations at lock time

[jdx]

Summary

Lock-time verification (current platform):

• During mise lock, for the current platform, downloads the artifact to a temp directory and runs full cryptographic verification (GitHub attestations, SLSA, cosign, minisign) before recording provenance in the lockfile
• Cross-platform entries still use detection-only (registry metadata) since we can't easily verify artifacts for other platforms
• If verification fails, provenance is not recorded (warning logged)

Install-time re-verification setting:

• Adds locked_verify_provenance setting (MISE_LOCKED_VERIFY_PROVENANCE, default: false, auto-enabled under MISE_PARANOID) that forces provenance re-verification at install time even when the lockfile already has both checksum and provenance

GitHub attestations at lock time:

• Enables GitHub artifact attestations as highest-priority provenance detection in detect_provenance_type() (what fix(install): detect github attestations provenance at lock-time #8781 intended)
• Applies the same force_verify logic to both aqua and github backends

Security context: Previously, detect_provenance_type() recorded provenance from aqua registry metadata without cryptographic verification, and mise install --locked skipped verify_provenance() entirely when the lockfile had both checksum and provenance. This meant provenance was never actually verified in the mise lock → mise install flow. Lock-time verification for the current platform closes this gap, and the locked_verify_provenance setting provides additional protection for paranoid users.

Supersedes #8781 — incorporates the GitHub attestations detection change while addressing the underlying security gap discussed there.

Test plan

• Verify cargo check passes (confirmed locally)
• Verify mise lock records github-attestations provenance for tools with github_artifact_attestations in aqua registry (e.g., jq >= 1.8.0) after downloading and verifying the artifact
• Verify mise lock logs verification activity for current platform tools with provenance
• Verify mise install --locked skips provenance verification by default (existing behavior preserved)
• Verify MISE_LOCKED_VERIFY_PROVENANCE=1 mise install --locked re-verifies provenance at install time
• Verify MISE_PARANOID=1 mise install --locked also re-verifies provenance
• Verify cross-platform lock entries still get provenance from metadata detection (no download)
• Verify the new setting appears in mise settings ls and schema

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes tool provenance verification behavior in the aqua and github backends, including new lock-time artifact downloads and optional install-time re-verification, which could affect install/lock reliability and CI rate limits.

Overview
Strengthens lockfile provenance semantics. mise lock now cryptographically verifies detected provenance for the current platform (downloading the artifact to a temp dir) before writing provenance into mise.lock for both aqua and github; if verification fails, provenance is omitted so it will be verified later.

Adds an opt-in install-time safety check. Introduces locked_verify_provenance (also enabled by paranoid) to force provenance re-verification during mise install even when the lockfile already contains checksum+provenance, and updates schema/docs accordingly.

Test/docs updates. E2E tests are adjusted for the new npm package-manager env var and for updated provenance expectations, and the cosign verification test now uses an aqua package with bundle-based cosign verification.

^{Reviewed by Cursor Bugbot for commit 810ef29. Bugbot is set up for automated code reviews on this repo. Configure here.}

[gemini-code-assist]

Code Review

This pull request introduces the locked_verify_provenance setting, which allows users to force cryptographic provenance re-verification during installation even when a lockfile is present. This behavior is also automatically enabled when paranoid mode is active. The changes include updates to the documentation, JSON schema, and the installation logic for both Aqua and GitHub backends. Feedback suggests extracting the duplicated logic for determining whether to force verification into a helper method on the Settings struct to improve maintainability.

[gemini-code-assist]

This logic to determine if provenance verification should be forced is duplicated in src/backend/github.rs. To improve maintainability, consider extracting this into a helper method on the Settings struct.

For example, in settings.rs:

impl Settings {
    // ...
    pub fn force_provenance_verify(&self) -> bool {
        self.locked_verify_provenance || self.paranoid
    }
}

Then, this block could be simplified to:

let force_verify = Settings::get().force_provenance_verify();
let platform_key = self.get_platform_key();
// ...

[gemini-code-assist]

This logic to determine if provenance verification should be forced is duplicated in src/backend/aqua.rs. To improve maintainability, consider extracting this into a helper method on the Settings struct.

For example, in settings.rs:

impl Settings {
    // ...
    pub fn force_provenance_verify(&self) -> bool {
        self.locked_verify_provenance || self.paranoid
    }
}

Then, this block could be simplified to:

let force_verify = Settings::get().force_provenance_verify();
if has_lockfile_integrity && !force_verify {
// ...

[greptile-apps]

Greptile Summary

This PR closes a meaningful security gap in the mise lock → mise install provenance flow. Previously, detect_provenance_type() recorded provenance from registry metadata or the attestation API with no cryptographic verification, and mise install --locked skipped verify_provenance() entirely when the lockfile already had checksum+provenance. The PR adds lock-time cryptographic verification for the current platform (download + attestation/SLSA/cosign/minisign check) in both the aqua and github backends, a locked_verify_provenance setting for opt-in re-verification at install time, and surfaces GitHub artifact attestations as the highest-priority provenance detection method.

• Cross-platform provenance gap: For non-current-platform targets, provenance is written to the lockfile from registry metadata or the attestation API — never cryptographically verified. On those platforms, mise install --locked with the default locked_verify_provenance = false will satisfy has_lockfile_integrity and skip all crypto checks. Users on a different OS/arch from the lock author get no cryptographic verification unless they opt in via locked_verify_provenance. The docs acknowledge this, but it's a material limitation worth tracking.
• Missing e2e coverage: The test plan lists MISE_LOCKED_VERIFY_PROVENANCE=1 and MISE_PARANOID=1 positive paths, but these are not implemented in e2e/lockfile/test_lockfile_provenance.

Confidence Score: 5/5

Safe to merge; all remaining findings are P2 style/improvement suggestions with no blocking defects

The core security logic is sound: lock-time provenance is cleared on failure (not kept as unverified), force_provenance_verify() is correctly wired into both backends, and the downgrade-attack detection is preserved. The addressed concern from prior threads (provenance kept on failure) was fixed in a9457d3. All open findings are P2: missing e2e coverage for locked_verify_provenance, a provenance-type mismatch between detection and verification in github.rs, and double artifact downloads. None of these block correct behavior.

src/backend/github.rs (provenance type inconsistency between detect and verify), e2e/lockfile/test_lockfile_provenance (missing locked_verify_provenance and MISE_PARANOID positive-path tests)

Important Files Changed

Filename	Overview
src/backend/aqua.rs	Adds GithubAttestations-first detect_provenance_type and verify_provenance_at_lock_time; clears provenance on failure so install-time runs as fallback
src/backend/github.rs	Adds API-based attestation detection and lock-time crypto verification for current platform; cross-platform entries remain detection-only
src/config/settings.rs	Adds force_provenance_verify() helper returning locked_verify_provenance
settings.toml	Adds locked_verify_provenance setting with MISE_LOCKED_VERIFY_PROVENANCE env var, default false, auto-enabled by paranoid
e2e/lockfile/test_lockfile_provenance	Tests SLSA lock-time provenance and downgrade detection; missing locked_verify_provenance and MISE_PARANOID positive-path coverage
e2e/backend/test_aqua_cosign	Switches sops to fork-cleaner which has bundle-based cosign matching the new native-only detection logic
e2e/backend/test_backend_missing_deps	Renames MISE_NPM_BUN to MISE_NPM_PACKAGE_MANAGER in npm backend missing-dep test
e2e-win/npm_backend.Tests.ps1	Updates Windows npm e2e test to MISE_NPM_PACKAGE_MANAGER env var
docs/dev-tools/mise-lock.md	Documents lock-time verification, cross-platform detection-only approach, and locked_verify_provenance setting
docs/paranoid.md	Documents that paranoid mode enables locked_verify_provenance provenance re-verification behavior
schema/mise.json	Adds locked_verify_provenance to JSON schema

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[mise lock] --> B{target.is_current?}
    B -- Yes --> C[detect_provenance_type]
    B -- No --> D[detect_provenance_type\ncross-platform]
    D --> E[registry metadata / API query only]
    E --> F[Write provenance to lockfile\nno crypto verification]
    C --> G{provenance detected?}
    G -- No --> H[No provenance in lockfile]
    G -- Yes --> I[verify_provenance_at_lock_time\ndownload artifact + crypto check]
    I -- Ok --> J[Write verified provenance\nto lockfile]
    I -- Err --> K[warn: lock-time failed\nprovenance = None]
    K --> L[No provenance in lockfile]
    J --> M[mise install --locked]
    F --> M
    H --> M
    L --> M
    M --> N{has_lockfile_integrity?\nchecksum AND provenance}
    N -- No --> O[verify_provenance\nfull crypto check]
    N -- Yes --> P{force_provenance_verify?\nlocked_verify_provenance or paranoid}
    P -- Yes --> O
    P -- No --> Q[ensure_provenance_setting_enabled\ndowngrade attack check only]

Loading

_{Reviews (10): Last reviewed commit: "fix(test): use tool with native cosign b..." | Re-trigger Greptile}

[github-actions]

Hyperfine Performance

mise x -- echo

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.4.3 x -- echo	22.2 ± 0.3	21.6	25.0	1.00
mise x -- echo	22.6 ± 0.5	21.8	26.1	1.02 ± 0.03

mise env

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.4.3 env	22.0 ± 0.6	20.9	24.1	1.00
mise env	22.9 ± 0.6	21.4	25.8	1.04 ± 0.04

mise hook-env

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.4.3 hook-env	22.4 ± 0.6	21.7	31.8	1.00
mise hook-env	22.9 ± 0.4	21.9	25.2	1.02 ± 0.03

mise ls

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.4.3 ls	19.7 ± 0.4	19.0	21.6	1.00
mise ls	20.1 ± 0.3	19.4	21.8	1.02 ± 0.03

xtasks/test/perf

Command	mise-2026.4.3	mise	Variance
install (cached)	148ms	149ms	+0%
ls (cached)	79ms	78ms	+1%
bin-paths (cached)	82ms	83ms	-1%
task-ls (cached)	824ms	793ms	+3%

[cursor]

Minisign missing asset now errors instead of warning

Medium Severity

The refactored run_minisign_check uses .wrap_err_with()? when a minisign signature asset is not found in a GitHub release, which propagates a hard error. The old verify_minisign code used if let Some(url) = url { ... } else { warn!(...); return Ok(()); }, gracefully skipping verification with a warning. Since verify_minisign now delegates to run_minisign_check, tools with minisign configured in the aqua registry but missing the signature asset in a specific release will now fail installation instead of installing with a warning.

Additional Locations (1)

• src/backend/aqua.rs#L1556-L1566

 

^{Reviewed by Cursor Bugbot for commit a9457d3. Configure here.}

[cursor]

Cosign empty asset_strs no longer handled gracefully

Medium Severity

The refactored run_cosign_check removes the empty-string guard that the old cosign verification had. The old code checked if asset_strs.is_empty() and produced an empty key_arg/sig_arg/bundle_arg, then skipped verification with if !key_arg.is_empty(). The new code passes potentially empty asset_strs directly to github_release_asset, which will likely error, turning a previously graceful skip into a hard install failure.

Additional Locations (1)

• src/backend/aqua.rs#L994-L1001

 

^{Reviewed by Cursor Bugbot for commit 701693e. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 3 total unresolved issues (including 2 from previous reviews).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 810ef29. Configure here.}

[cursor]

Refactored SLSA check turns graceful warnings into hard errors

Medium Severity

The refactored run_slsa_check removes graceful fallback handling that existed in the old verify_slsa code. Previously, when a SLSA asset was missing from a release (empty asset_strs or github_release_asset returning Err), the old code logged a warn! and returned Ok(()), allowing installation to proceed. The new shared helper propagates these as hard errors via ?. Since verify_slsa calls run_slsa_check with ? at install time, tools that have SLSA configured in the aqua registry but lack SLSA assets for a specific version/platform will now fail to install instead of succeeding with a warning.

Additional Locations (1)

• src/backend/aqua.rs#L1590-L1601

 

^{Reviewed by Cursor Bugbot for commit 810ef29. Configure here.}