jdx/mise · error

the release list in github.com/

Error message

the release list in github.com/{repo} is for {}, not {project}

What it means

mise's packslip backend fetched a signed release list from the GitHub repository, but the project identity recorded inside the signed list's predicate does not match the project mise was asked to install. This is a safety check against installing a manifest published by a different (possibly hijacked or misconfigured) repository than the one requested.

Solutions

1. Fix the project field in the packslip manifest published in the repo's release list to match the requested project name
2. Correct the registry entry in registry/ so the project name matches the manifest's predicate.project
3. If intentionally installing from a different project, change the requested project to the one the manifest actually declares

Example fix

// before (registry entry)
foo = 'packslip:acme/foo-cli'
// after — match the manifest's predicate.project
foo-cli = 'packslip:acme/foo-cli'

// mise will verify this itself; as a packslip author, check the manifest matches:
let manifest_project = /* read from your packslip manifest */;
assert_eq!(manifest_project, env!("CARGO_PKG_NAME"), "predicate.project must equal the registry project name");

null

null

When it happens

Trigger: Calling packslip version listing or install (via vendor_entry/vendor_versions/recommendation → github_list) where the repo's release list asset embeds a predicate.project different from the registry entry's project name — e.g. the registry maps project 'foo' to a repo whose packslip manifest declares project 'foo-cli'.

Common situations: A registry entry points at the wrong repo; a project was renamed in its packslip manifest but the mise registry entry still uses the old name; a fork or squatted repo publishes a manifest for a different project.

Understand the failure class

Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.

Related errors

• mise.lock says signed , but this release is signed by …
• packslip: : this release . If the vendor announced the…
• the release list of packslip
• published a stamp list for before (sequence ) but now…
• mise.lock says the vendor's own packslip was accepted for

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

Appendix: source

Thrown at src/backend/packslip.rs:783

            .get_text_request(&url)
            .headers(&headers)
            .send()
            .await
        {
            Ok(text) => text,
            Err(err) if crate::http::error_code(&err) == Some(404) => {
                packslip_pins::check_missing_list(project)?;
                return Ok(None);
            }
            Err(err) => {
                return Err(err)
                    .wrap_err_with(|| format!("fetching the release list of packslip:{project}"));
            }
        };
        let list = verify_release_list(&text, &pin, !opts.allow_unlogged())
            .wrap_err_with(|| format!("verifying the release list of packslip:{project}"))?;
        if list.predicate.project != project {
            bail!(
                "the release list in github.com/{repo} is for {}, not {project}",
                list.predicate.project
            );
        }
        check_sequence(project, &list)?;
        Ok(Some(list))
    }

    /// What the vendor themselves say about a version, from the release
    /// list they sign: a withdrawal refuses it outright, and the entry pins
    /// the manifest's digest. `None` only when no signed list covers the
    /// version, which a project served from a GitHub repository is allowed
    /// to do and any other project is not.
    async fn vendor_entry(
        &self,
        project: &str,
        tv: &ToolVersion,
        pin: &Pin,

View on GitHub (pinned to 533346cc37)