jdx/mise · error

no trusted public keys available for verification

Error message

no trusted public keys available for verification

What it means

verify_detached in src/gpg.rs validates detached GPG signatures against a set of trusted public keys. Before doing any cryptographic work it parses the armored key material and throws this error if the resulting key list is empty, meaning there are no trusted keys to verify against.

Source

Thrown at src/gpg.rs:41

}

/// Verify a detached signature entirely in-process (no external `gpg` binary).
///
/// `public_keys_asc` is one or more ASCII-armored public key blocks (a trusted keyring bundled
/// with mise). `open_data` returns a fresh reader over the signed content each time it is called,
/// so the content can be streamed (and, if necessary, re-read for another candidate key) without
/// buffering large files in memory.
///
/// Verification succeeds if any signature validates against any of the trusted keys or their
/// subkeys, mirroring `gpg --verify` against an imported keyring.
fn verify_detached<R, F>(public_keys_asc: &str, signature: &[u8], open_data: F) -> Result<()>
where
    R: Read,
    F: Fn() -> Result<R>,
{
    let keys = parse_public_keys(public_keys_asc)?;
    if keys.is_empty() {
        bail!("no trusted public keys available for verification");
    }
    let signatures = parse_signatures(signature)?;
    if signatures.is_empty() {
        bail!("no signature found to verify");
    }

    // Fast path: only try keys whose id/fingerprint matches the signature's issuer, so the signed
    // content is hashed at most once in the common case.
    for sig in &signatures {
        if verify_against_keys(sig, &keys, &open_data, true)? {
            return Ok(());
        }
    }
    // Fallback: try every trusted key, but only for signatures that carried no usable issuer
    // hint. A signature that named an issuer we don't trust is genuinely unverifiable, so skip it
    // rather than re-hashing the (potentially large) content against every key.
    for sig in signatures.iter().filter(|sig| !has_issuer(&sig.signature)) {
        if verify_against_keys(sig, &keys, &open_data, false)? {

View on GitHub (pinned to afd2eddd3a)

Solutions

  1. Ensure the public_keys_asc argument (or mise setting feeding it) contains valid ASCII-armored public key blocks starting with -----BEGIN PGP PUBLIC KEY BLOCK-----
  2. Re-download the trusted keys from the official project keyserver/release repo and point the setting at the correct file
  3. Check for typos or empty values in the relevant settings/env vars (e.g. node.gpg_keys / swift keys config)
  4. If GPG verification is not wanted, disable checksum/signature verification for that backend instead of passing empty keys

Example fix

// before
let keys = ""; // or a file with only release notes
verify_node(&archive, sig, keys)?;
// after
let keys = std::fs::read_to_string("node_keys.asc")?; // contains BEGIN PGP PUBLIC KEY BLOCK
verify_node(&archive, sig, keys)?;
Defensive patterns

Strategy: validation

Validate before calling

let keys = std::fs::read_to_string(key_path)?;
if !keys.contains("-----BEGIN PGP PUBLIC KEY BLOCK-----") {
    anyhow::bail!("key file {} contains no public key blocks", key_path);
}
verify_node(&archive, sig, keys)?;

Prevention

When it happens

Trigger: Calling verify_node, verify_swift, or verify_swift_bytes with a public_keys_asc argument whose armored text contains no parseable SignedPublicKey blocks (empty string, whitespace, or only non-key ASCII-armored blocks).

Common situations: Misconfigured mise settings where the trusted keyring variable is empty; a truncated or corrupted armor file; passing only a signature file instead of key material; upstream project changed its key distribution so the configured key list resolves to nothing.

Understand the failure class

Background: "must not be empty", "cannot be empty" — required-field validation errors across open-source libraries — this error's family across 41 libraries.

Related errors


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