content-level SLSA verification found no regular files in…

Error message

content-level SLSA verification found no regular files in archive

What it means

During content-level SLSA provenance verification, mise extracts the archive and hashes each regular file it finds. `validate_archive_content_files` is given the list of regular files extracted from the archive; if that list is empty there is nothing to verify, so verification fails closed rather than silently passing an empty archive.

Solutions

Check the downloaded archive with `tar tf <file>` to confirm it actually contains regular files at the expected depth
Verify the registry/backend entry's archive path and strip_components match the upstream release layout
Re-run the install after clearing the mise cache (`mise cache clear`) in case a truncated download was cached
If upstream changed archive layout, update the aqua/packslink recipe or pin to a version that still ships the expected layout

Example fix

// registry recipe before: strips away the only top-level dir that held the files
strip_components = 2
// after: keep the level containing regular files
strip_components = 1

Defensive patterns

Strategy: validation

Validate before calling

tar -tf tool.tar.gz | awk -F/ 'NF>1' | head  # confirm regular files exist below the stripped prefix

Prevention

Verify archives with `tar tf` before relying on a new registry/backend recipe
Keep strip_components no larger than the archive's real nesting depth
Clear the mise cache after changing recipes so stale archives are not reused

When it happens

Trigger: Content-level SLSA verification (e.g. `mise install` of a tool whose backend verifies SLSA provenance by contents) where the archive, after extraction and strip-components processing, yields zero regular files — e.g. an archive containing only directories/symlinks, a wrong archive format, or a strip_components setting that strips away everything.

Common situations: A packslip/SLSA manifest points at the wrong artifact; the upstream project changed its release archive layout; a misconfigured `strip_components` in the backend recipe removes the top-level directory containing all files; downloading a stub/redirect HTML page saved as the archive.

Understand the failure class

Background: EmptyResultError / "no results found": when an API or scraper succeeds but returns zero rows — this error's family across 9 libraries.

Related errors

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

Appendix: source

Thrown at src/file.rs:2746

    validate_archive_content_files(files)
}

fn sha256_reader(reader: &mut impl Read) -> Result<String> {
    let mut hasher = Sha256::new();
    let mut buf = [0; 8192];
    loop {
        let n = reader.read(&mut buf)?;
        if n == 0 {
            break;
        }
        hasher.update(&buf[..n]);
    }
    Ok(hex::encode(hasher.finalize()))
}

fn validate_archive_content_files(files: Vec<ArchiveContent>) -> Result<Vec<ArchiveContent>> {
    if files.is_empty() {
        bail!("content-level SLSA verification found no regular files in archive");
    }
    let mut names = std::collections::HashSet::new();
    for file in &files {
        if !names.insert(file.name.clone()) {
            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()),

View on GitHub (pinned to 533346cc37)