NousResearch/hermes-agent · error · RuntimeError

No checksum entry for {asset_name} in {checksum_file.name}

Error message

No checksum entry for {asset_name} in {checksum_file.name}

What it means

After downloading checksums.txt, the installer parses standard `sha256sum` output (`<hex> <filename>`) and looks for a line whose last field equals the computed asset name. If no line matches, it refuses to proceed — there is no unsigned path. This almost always means the release's asset naming scheme and the locally computed asset name have drifted.

Source

Thrown at agent/proxy_sources/iron_proxy.py:640

        # A present signature that does NOT verify is a tamper signal — fail hard.
        raise RuntimeError(
            "iron-proxy checksums.txt failed GPG signature verification — "
            "refusing to install (possible release-channel tampering). "
            f"gpg: {verify.stderr.decode('utf-8', 'replace')[:300]}"
        )
    logger.info("Verified iron-proxy checksums.txt GPG signature.")
    return True


def _expected_sha256(checksum_file: Path, asset_name: str) -> str:
    """Parse the standard ``sha256sum`` output: ``<hex>  <filename>``."""

    text = checksum_file.read_text(encoding="utf-8", errors="replace")
    for line in text.splitlines():
        parts = line.strip().split()
        if len(parts) >= 2 and parts[-1] == asset_name:
            return parts[0]
    raise RuntimeError(
        f"No checksum entry for {asset_name} in {checksum_file.name}"
    )


def _sha256_file(path: Path) -> str:
    h = hashlib.sha256()
    with open(path, "rb") as f:
        for chunk in iter(lambda: f.read(65536), b""):
            h.update(chunk)
    return h.hexdigest()


def _pick_tar_member(tf: tarfile.TarFile, binary_name: str) -> tarfile.TarInfo:
    """Find the binary inside the upstream tar.

    iron-proxy's archive is typically flat (binary at root) but we tolerate
    a top-level directory.  Members must be regular files with a leaf name
    matching ``binary_name``, no absolute paths, and no ``..`` traversal.

View on GitHub (pinned to c896c09c42)

Solutions

  1. Open the release page for _IRON_PROXY_VERSION and compare the published asset filenames against what the error's asset_name implies; align the naming in _platform_asset_name (or the version pin) with the actual release.
  2. If your arch genuinely has no asset, install the binary manually on a supported host or build from source and place it where find_iron_proxy() looks.
  3. Downgrade/pin to the last release whose checksums.txt contains your asset name until the module is updated.
Defensive patterns

Strategy: validation

Validate before calling

import urllib.request, json

def asset_in_release(api_url: str, asset_name: str) -> bool:
    with urllib.request.urlopen(api_url, timeout=15) as r:
        assets = [a["name"] for a in json.load(r).get("assets", [])]
    return asset_name in assets

Try / catch

try:
    find_iron_proxy(install_if_missing=True)
except RuntimeError as e:
    if "No checksum entry" in str(e):
        # version pin / asset naming drift — update pin or install manually
        raise

Prevention

When it happens

Trigger: find_iron_proxy(install_if_missing=True) when _platform_asset_name() produces a name like iron-proxy_vX_linux_arm64.tar.gz but the release names assets differently (e.g. dropped the arch suffix, switched to .zip, or renamed to iron-proxy-linux-arm64.tar.gz). Also triggered by checksums.txt using different path prefixes per line.

Common situations: Upgrading iron-proxy upstream changed asset naming between versions while _IRON_PROXY_VERSION was bumped; running on an arch whose asset the release doesn't publish (e.g. linux armv7) so its entry simply isn't in checksums.txt.

Related errors

AI-assisted analysis of NousResearch/hermes-agent@c896c09c42 (2026-08-14). Data as JSON: /api/errors/31b53fc21da91d94. Report an issue: GitHub.