jdx/mise · error

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

Error message

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

What it means

Same project-binding guard as the URL-based list, but for lists discovered via a GitHub repository. After verifying the list fetched from github.com/{repo}, mise checks `list.predicate.project` against the requested project and refuses if the list belongs to a different project, preventing a repo's list from being used to install another project's artifacts.

Source

Thrown at src/backend/packslip.rs:678

            .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 afd2eddd3a)

Solutions

  1. Point the packslip pin at the correct GitHub repository that publishes lists for this project
  2. Fix the project name/slug in your config to match the list's subject
  3. Contact the vendor if their repo publishes a list with the wrong project field

Example fix

// before
[tools."packslip:acme"]
github_repo = "acme-org/acme-lib-releases"
// after
[tools."packslip:acme"]
github_repo = "acme-org/acme-releases"
Defensive patterns

Strategy: validation

Validate before calling

if (!githubRepo.split('/').pop().startsWith(projectBaseName)) {
  console.warn(`repo ${githubRepo} may not publish lists for ${project}`);
}

Prevention

When it happens

Trigger: Calling `github_list` (from `vendor_entry`, `recommendation`, or `vendor_versions`) when the verified list obtained from the GitHub repo has a `predicate.project` different from the requested packslip project.

Common situations: The GitHub repo configured for the packslip backend hosts release lists for a differently-named project (repo renamed or forked); a typo in the project slug; a fork serving the upstream project's lists is pinned by mistake.

Related errors


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