lockfile generation would downgrade additional artifact…

Error message

lockfile generation would downgrade additional artifact provenance; previous files were preserved

What it means

Beyond the primary artifact, lockfiles record provenance for additional artifacts. During generation, each old additional artifact is paired with its replacement (in configured order, handling reordering); if the replacement's provenance is a downgrade relative to what was recorded, `ensure_no_downgrade` aborts and preserves the previous files.

Solutions

Check the specific artifact's attestation availability upstream for the target version
Keep using the backend (e.g. packslip:) that provides provenance for all artifacts
Re-enable attestation-related settings if they were turned off
If the weaker provenance is accepted knowingly, clear the recorded provenance for that entry first (manual lockfile review)

Defensive patterns

Strategy: validation

Validate before calling

for artifact in new_entry.additional_artifacts {
    if artifact.provenance.is_none() {
        // a replacement artifact lacks provenance — generation would downgrade
    }
}

Prevention

Verify attestation coverage for all per-platform artifacts of a release, not just the primary one
Keep packslip backends for tools that publish signed manifests
Regenerate lockfiles on a platform matrix so all additional artifacts are checked
Don't mix backends for primary vs additional artifacts of the same tool

When it happens

Trigger: Regenerating a lockfile where an additional artifact (extra platform/binary artifact) previously had provenance but the newly resolved replacement artifact lacks it or has weaker provenance, with `packslip_signer_replaces_provenance` in effect for packslip backends.

Common situations: Upstream stopped attesting some per-platform artifacts but not others; switching backends for extra artifacts; partial attestation coverage in a new release; mirrors lacking provenance for secondary artifacts.

Understand the failure class

Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.

Related errors

AI-assisted analysis of jdx/mise@533346cc37 (2026-09-17). Data as JSON: /api/errors/5d80184cebcff283. Report an issue: GitHub.

Appendix: source

Thrown at src/lockfile/generate.rs:812

    // Preserve identities across reordering, then pair replaced URLs in their
    // configured order so version upgrades retain the previous trust baseline.
    let mut replacements = new.additional_artifacts.iter().filter(|artifact| {
        !old.additional_artifacts
            .iter()
            .any(|old| old.url == artifact.url)
    });
    for artifact in &old.additional_artifacts {
        let replacement = new
            .additional_artifacts
            .iter()
            .find(|new| new.url == artifact.url)
            .or_else(|| replacements.next());
        if provenance_is_downgrade(
            artifact.provenance.as_ref(),
            replacement.and_then(|a| a.provenance.as_ref()),
            packslip_signer_replaces_provenance,
        ) {
            bail!(
                "lockfile generation would downgrade additional artifact provenance; previous files were preserved"
            );
        }
    }
    Ok(())
}

fn provenance_is_downgrade(
    old: Option<&ProvenanceType>,
    new: Option<&ProvenanceType>,
    packslip_signer_replaces_provenance: bool,
) -> bool {
    if packslip_signer_replaces_provenance
        && old.is_some_and(ProvenanceType::is_github_attestations)
    {
        return false;
    }
    new < old

View on GitHub (pinned to 533346cc37)