jdx/mise · critical

content-level SLSA verification rejected unsafe archive path

Error message

content-level SLSA verification rejected unsafe archive path: {}

What it means

During content-level SLSA verification every entry path is normalized, and any component that is '..', a root directory, or a Windows prefix is rejected - the tar/zip traversal guard mirroring sanitize_7z_entry_path. Like the 7z variant, this error indicates a hostile or malformed archive attempting to address paths outside the extraction root, and it should be treated as a security signal.

Source

Thrown at src/file.rs:2578

            bail!(
                "content-level SLSA verification found duplicate installed archive path: {}",
                file.name
            );
        }
    }
    Ok(files)
}

fn normalize_archive_content_path(path: &Path, strip_components: usize) -> Result<String> {
    let mut parts = Vec::new();
    for component in skip_curdir_components(path) {
        match component {
            std::path::Component::Normal(part) => parts.push(part.to_string_lossy().to_string()),
            std::path::Component::CurDir => {}
            std::path::Component::ParentDir
            | std::path::Component::RootDir
            | std::path::Component::Prefix(_) => {
                bail!(
                    "content-level SLSA verification rejected unsafe archive path: {}",
                    path.display()
                )
            }
        }
    }
    if strip_components > parts.len() {
        bail!(
            "content-level SLSA verification stripped all components from archive path: {}",
            path.display()
        );
    }
    let parts = &parts[strip_components..];
    if parts.is_empty() {
        bail!(
            "content-level SLSA verification stripped all components from archive path: {}",
            path.display()
        );

View on GitHub (pinned to 9dcfcaa0dc)

Solutions

Halt and treat as a security incident: do not extract or install; preserve the artifact for analysis
Inspect the archive non-destructively with tar -tvf or unzip -l to identify the crafted entry
Re-download from the official source and verify checksum and signature before retrying

Defensive patterns

Strategy: validation

Validate before calling

// pre-scan entries for traversal patterns before verification/extraction
for name in list_archive_entry_names(&archive, format)? {
    let norm = name.replace('\\', "/");
    if norm.split('/').any(|c| c == "..") || norm.starts_with('/') {
        anyhow::bail!("unsafe archive path {name:?}; refusing to verify or extract");
    }
}

Try / catch

match archive_content_files(&archive, format, strip) {
    Ok(files) => verify_subjects(&files)?,
    Err(e) if e.to_string().contains("rejected unsafe archive path") => {
        // fail closed: never downgrade, never extract; treat as supply-chain incident
        return Err(e.wrap_err("path traversal detected in archive; artifact rejected"));
    }
    Err(e) => return Err(e),
}

Prevention

Verify provenance/checksums of downloaded archives before any parsing
Treat '..' or absolute-path entries as malicious by default - abort and report, do not sanitize-and-continue
Keep the failure closed: do not fall back to extraction when verification rejects a path

When it happens

Trigger: A tar or zip entry named like ../evil, /etc/passwd, or C:\x reaches normalize_archive_content_path while archive_content_files enumerates the archive.

Common situations: Tampered release asset; malicious archive probing an automated installer; supply-chain incident response.

Related errors

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