`mcpb sign` produces bundles that strict zip parsers reject - including Claude Desktop itself ("Invalid comment length")

[jeffreyaven]

Describe the bug
mcpb sign appends the signature block (MCPB_SIG_V1 + 4-byte LE length + DER PKCS#7 + MCPB_SIG_END) after the zip's end-of-central-directory (EOCD) record without declaring those bytes in the EOCD comment-length field. The result is not a strictly valid zip: the EOCD declares a 0-byte comment, but trailing data follows. Lenient parsers (Python zipfile, Info-ZIP unzip) tolerate this; strict parsers (yauzl) reject the file outright. Claude Desktop uses a strict parser, so a signed .mcpb cannot be previewed or installed in Claude Desktop at all - signing a bundle currently breaks it for the flagship consumer of the format.

To Reproduce
Steps to reproduce the behavior:

1. npx --yes @anthropic-ai/mcpb pack my-extension/ test.mcpb
2. npx --yes @anthropic-ai/mcpb sign test.mcpb --self-signed
3. In Claude Desktop: Settings -> Extensions -> Install Extension -> select test.mcpb
4. The extension preview fails with an "Invalid comment length" unzip error (see Logs). The same bundle installs fine before signing.

Expected behavior
Signed bundles remain installable in Claude Desktop (and parseable by any spec-strict zip reader). Trailing data can be made zip-legal by declaring it as the archive comment: patch the 2-byte comment-length field at EOCD offset +20 to the size of the appended signature block. Verified empirically: with that one patch, the same signed bundle previews and installs correctly in Claude Desktop, and extractSignatureBlock still finds the signature (it scans backwards for MCPB_SIG_END and is unaffected by the EOCD field).

Logs

Failed to preview extension: Failed to read or unzip file: Invalid comment length.
Expected: 2264. Found: 0. Are there extra bytes at the end of the file?
Or is the end of central dir signature `PK☺☻` in the comment?

2264 is exactly the appended signature block in this repro: 11-byte header + 4-byte length + 2237-byte DER + 12-byte footer.

Additional context

• @anthropic-ai/mcpb 2.1.2; Claude Desktop for Windows (current as of June 2026).
• Implementation wrinkle for the fix: the signature digest is computed over the pre-signature bytes, so the EOCD patch must happen before signing or the digest goes stale. The signature length for a given cert/key is deterministic, so a two-pass sign (or patching with the known length upfront) resolves the chicken-and-egg.
• Zip comments cap at 65,535 bytes, which comfortably fits typical PKCS#7 blocks (~2-6 KB).
• Combined with mcpb verify reports every signed bundle as "Extension is not signed" (node-forge p7.verify is unimplemented) #277 (mcpb verify always reports unsigned), the signing feature is currently not usable end to end: signed bundles fail verification in the CLI and fail installation in Claude Desktop.

[David-BS]

Confirming this on Claude Desktop for macOS (Intel x86_64) with a type: binary bundle.

After mcpb sign, Install Extension fails immediately with:

Failed to read or unzip file: Invalid comment length. Expected: 1410. Found: 0

The 1410 is the exact size of the detached signature footer appended by mcpb sign
(MCPB_SIG_V1 header + 4-byte length + PKCS#7 DER + MCPB_SIG_END trailer). The loader
appears to hand the whole file — footer included — to a strict ZIP reader, which rejects the
trailing bytes as an invalid end-of-archive comment. So signing a bundle prevents it from
installing, the opposite of the intended effect.

The bundle and signature themselves are sound — only the loader's reader rejects them:

• unzip and ditto (which locate the EOCD from the end of the file) extract the signed
  .mcpb without error.
• The footer's PKCS#7 verifies out-of-band:
  openssl cms -verify -inform DER -in sig.der -content original_zip.bin -noverify -binary
  → CMS Verification successful, and security verify-cert -p codeSign passes.

The unsigned version extracts cleanly with unzip/ditto; adding the signature is what
introduces the trailing footer the loader chokes on, and re-signing reproduces the failure
deterministically. Happy to share a minimal repro bundle if useful.

[jeffreyaven]

thanks @David-BS - looks like this was already fixed on main by #204 ("update ZIP EOCD comment_length when signing"), which also added a regression test. The remaining gap is just a release: the latest published CLI is still v2.1.2, which predates #204, so npx @anthropic-ai/mcpb sign still produces broken bundles for anyone on the released version.

Any plans to cut a release that includes it? Happy to test once it's out.

[David-BS]

Thanks @jeffreyaven — that matches exactly what I saw. Signing with the published CLI (2.1.2) appends the PKCS#7 footer but leaves the ZIP EOCD comment_length at 0, so the bundle is a malformed archive that the loader's strict reader correctly rejects (Info-ZIP tolerates it by scanning the EOCD from the end, which masked the issue locally). Good to know #204 already fixes the signer and adds a regression test — a CLI release that includes it would let me re-test the signed path, and I'm happy to test once it's out.

One thing worth keeping separate so it doesn't get conflated when #204 ships: my deployment actually ships unsigned (signature deferred), so #204 won't unblock my install on its own. For an unsigned server.type: binary bundle the blocker I hit is a different one — installing unpacked succeeds, but the host falls back to "basic execution" for type: binary and fails to spawn (ENOENT, not EACCES — a resolution/handler gap, not a permissions one). I filed that separately as #282.

So #278 closing once a fixed CLI is out is real progress for the signed path, but #282 is the one gating one-click install of a binary server. Both are host/tooling-side; the binary itself starts and speaks MCP fine when launched directly.

[jeffreyaven]

thanks @David-BS makes sense, and good call separating them. #282 is the real blocker for unsigned type: binary - we ship unsigned too, so I'll watch it; we haven't hit it because our install path is the packaged .mcpb flow rather than unpacked, but it's the same handler territory. Will keep an eye on #282.