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
- Change strip_components to 0 or 1 for the verified asset
- Skip content-level verification for this asset (fall back to plain checksum verification)
- 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
- Keep verified assets at one nesting level
- Keep SLSA verification and strip_components settings reviewed together
- Document the 0/1 limit in project packaging guides
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
- content-level SLSA verification does not support…
- content-level SLSA verification found duplicate installed…
- content-level SLSA verification found no regular files in…
- content-level SLSA verification only supports archive…
- additional asset ' ' is not an archive
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::GzView on GitHub (pinned to 533346cc37)