jdx/mise · error

content-level SLSA verification only supports…

Error message

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

What it means

archive_content_files, used for content-level SLSA provenance verification (hashing archive members), only supports strip_components of 0 or 1 because path normalization is implemented only for those cases. Values above 1 are rejected up front. This is a deliberate limitation of the verification feature, not a generic extraction limit.

Solutions

  1. Change strip_components to 0 or 1 for the verified asset
  2. Skip content-level verification for this asset (fall back to plain checksum verification)
  3. Repackage the artifact so one-level stripping suffices

Example fix

// before
strip_components = 2
// after
strip_components = 1
Defensive patterns

Strategy: validation

Validate before calling

if (config.strip_components > 1) throw new Error("SLSA content verification requires strip_components 0 or 1");

Type guard

function validForSlsaVerify(c) { return c.strip_components <= 1; }

Prevention

When it happens

Trigger: Invoking SLSA content verification on an archive configured with strip_components >= 2.

Common situations: packslip/aqua-style configs copied from setups that used strip_components=2 for extraction; registry entries with deeply nested binaries.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors


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

Appendix: source

Thrown at src/file.rs:2635

#[derive(Debug, Clone)]
pub(crate) 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(crate) 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 533346cc37)