jdx/mise · error · eyre::Report

content-level SLSA verification does not support non-regular

Error message

content-level SLSA verification does not support non-regular archive entry: {}

What it means

While hashing tar entries for content-level SLSA verification, any entry that is neither a regular file nor a directory (symlink, hardlink, FIFO, device node) is rejected. Links let an archive reference content outside itself, which provenance cannot hash meaningfully, so verification fails closed per the documented stricter-than-extraction contract.

Source

Thrown at src/file.rs:2493

fn archive_content_files_tar(
    archive_path: &Path,
    format: ExtractionFormat,
    strip_components: usize,
) -> Result<Vec<ArchiveContent>> {
    let tar = open_tar(format, archive_path)?;
    let mut archive = Archive::new(tar);
    let mut files = Vec::new();

    for entry in archive.entries()? {
        let mut entry = entry?;
        let path = entry.path()?.into_owned();
        let entry_type = entry.entry_type();
        if entry_type == EntryType::Directory {
            continue;
        }
        if entry_type != EntryType::File {
            bail!(
                "content-level SLSA verification does not support non-regular archive entry: {}",
                path.display()
            );
        }
        let name = normalize_archive_content_path(&path, strip_components)?;
        let sha256 = sha256_reader(&mut entry)?;
        files.push(ArchiveContent { name, sha256 });
    }

    validate_archive_content_files(files)
}

fn archive_content_files_zip(
    archive_path: &Path,
    strip_components: usize,
) -> Result<Vec<ArchiveContent>> {
    let f = File::open(archive_path)?;
    let mut archive = ZipArchive::new(f)

View on GitHub (pinned to 9dcfcaa0dc)

Solutions

1. Use an asset variant without link entries, or fall back to artifact-level verification for that tool
2. If you produce the artifact, repack with links dereferenced (tar -h / --dereference)

// pre-scan the tarball for link entries before enabling content verification
let mut tar = tar::Archive::new(flate2::read::GzDecoder::new(std::fs::File::open(&archive)?));
for entry in tar.entries()? {
    let entry = entry?;
    let t = entry.header().entry_type();
    anyhow::ensure!(
        t.is_file() || t.is_dir(),
        "archive contains a link entry ({}); content-level SLSA will fail closed",
        entry.path()?.display()
    );
}

match archive_content_files(&archive, format, strip) {
    Ok(files) => verify_subjects(&files)?,
    Err(e) if e.to_string().contains("non-regular archive entry") => {
        warn!("archive contains links; falling back to artifact-level verification: {e:#}");
        verify_artifact_level(&archive)?;
    }
    Err(e) => return Err(e),
}

When it happens

Trigger: A tarball containing symlink or hardlink entries (e.g. libfoo.so -> libfoo.so.1, or usr/bin/x -> x.gnu alternatives links) is installed while content-level verification is enabled.

Common situations: Library release tarballs shipping .so symlink chains; tarballs built by tools that deduplicate identical files into hardlinks; GNU-style packages with alternatives symlinks.

Related errors

• content-level SLSA verification does not support symlink arc
• content-level SLSA verification only supports strip_componen
• content-level SLSA verification only supports archive format
• content-level SLSA verification found no regular files in ar
• content-level SLSA verification found duplicate installed ar

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