jdx/mise · error · eyre::Report

content-level SLSA verification only supports strip_componen

Error message

content-level SLSA verification only supports strip_components values of 0 or 1

What it means

archive_content_files hashes every regular file in an archive for content-level SLSA provenance verification, and its path normalization (normalize_archive_content_path) only strips 0 or 1 leading components. A larger strip_components would make provenance subject-name matching ambiguous, so verification fails closed per the function's documented stricter-than-extraction contract.

Source

Thrown at src/file.rs:2444

#[derive(Debug, Clone)]
pub struct ArchiveContent {
    pub name: String,
    pub sha256: String,
}

/// Return the regular files in an archive after applying strip-components.
///
/// This is intentionally stricter than extraction: content-level provenance is
/// only safe when every installed regular file is covered, so ambiguous archive
/// entries (links, unsafe paths, stripped-away file names, unsupported formats)
/// fail closed instead of being ignored.
pub fn archive_content_files(
    archive_path: &Path,
    format: ExtractionFormat,
    strip_components: usize,
) -> Result<Vec<ArchiveContent>> {
    if strip_components > 1 {
        bail!("content-level SLSA verification only supports strip_components values of 0 or 1");
    }

    match format {
        ExtractionFormat::TarGz
        | ExtractionFormat::TarXz
        | ExtractionFormat::TarBz2
        | ExtractionFormat::TarZst
        | ExtractionFormat::Tar
        | ExtractionFormat::TarBr
        | ExtractionFormat::TarLz4
        | ExtractionFormat::TarSz => {
            archive_content_files_tar(archive_path, format, strip_components)
        }
        ExtractionFormat::Zip => archive_content_files_zip(archive_path, strip_components),
        ExtractionFormat::SevenZip => {
            bail!("content-level SLSA verification does not support 7z archives")
        }
        ExtractionFormat::Gz

View on GitHub (pinned to 9dcfcaa0dc)

Solutions

1. Reduce strip_components to 0 or 1 by using an archive layout with at most one wrapping directory
2. Fall back to artifact-level (whole-archive) verification for that tool if the layout cannot change
3. Repackage the asset without double nesting if you control the release

Example fix

# before
[tools]
mytool = { version = '1.0', strip_components = 2 }

# after
[tools]
mytool = { version = '1.0', strip_components = 1 }

if slsa_content_verification_enabled && opts.strip_components > 1 {
    anyhow::bail!("content-level SLSA needs strip_components <= 1; fix the tool's archive layout or use artifact-level verification");
}

When it happens

Trigger: Content-level SLSA verification runs while the tool's install options carry strip_components of 2 or more (e.g. strip_components: 2 in mise.toml or an aqua registry entry), so archive_content_files is called with strip_components > 1.

Common situations: A tool's archive nests the payload two directories deep and config compensates with strip 2; enabling stricter SLSA verification on existing configs that already used strip_components >= 2.

Related errors

• content-level SLSA verification found duplicate installed ar
• content-level SLSA verification stripped all components from
• content-level SLSA verification only supports archive format
• content-level SLSA verification does not support non-regular
• content-level SLSA verification does not support symlink arc

AI-assisted analysis of jdx/mise@9dcfcaa0dc (2026-08-17). Data as JSON: /api/errors/e2859399224a542a. Report an issue: GitHub.