fix: sign the bytes that are actually written to disk

[bryan-anthropic]

Problem

signMcpbFile computes the detached PKCS#7 signature over the pre-patch buffer, then grows the ZIP EOCD comment_length afterwards:

p7.content = forge.util.createBuffer(mcpbContent);   // digest binds to THIS
p7.sign({ detached: true });                          // signing completes here
...
const updatedContent = Buffer.from(mcpbContent);      // copy, so mcpbContent is untouched
updatedContent.writeUInt16LE(..., eocdOffset + 20);   // only the copy is patched
writeFileSync(mcpbPath, Buffer.concat([updatedContent, signatureBlock]));

The two bytes at eocdOffset + 20 therefore differ between the content that was signed and the content on disk. verifyMcpbFile reconstructs the signed content as everything before the signature header — the patched version — and so does any other standards-compliant verifier.

Reproduction

Packing a bundle with mcpb pack, signing it, then verifying the detached signature with OpenSSL:

differing byte offsets  : [455,456]
EOCD offset             : 435  (comment_length field at 455)

against bytes ACTUALLY ON DISK          => FAILED: PKCS7_signatureVerify:digest failure
against pre-patch bytes (never on disk) => VERIFICATION SUCCESSFUL

The signature validates only against bytes that never reach disk. Every signed bundle is affected — the comment_length always grows by a nonzero amount.

This is a regression: at the parent of the commit that introduced the comment_length patch, the same reproduction gives VERIFICATION SUCCESSFUL against the on-disk bytes.

Fix

The comment_length depends on the signature block length, and the signature covers the patched bytes, so the two are mutually dependent. This patches the EOCD field first using the length of a trial signature, then re-signs, iterating until the block length stops changing. It converges immediately in practice, because the content is detached and does not affect the DER encoding size. A bound guards against a length that never stabilizes, and an oversized block now raises a clear error instead of silently throwing from writeUInt16LE.

Tests

Adds a regression test that pulls the messageDigest authenticated attribute out of the signature and asserts it equals the SHA-256 of the on-disk pre-signature bytes. It fails on the current code with the expected digest mismatch and passes with the fix. Extraction uses node-forge's ASN.1 parser rather than shelling out to OpenSSL, so it runs on all CI platforms.

The existing tests could not catch this — they accept ["self-signed", "unsigned"] as passing, and the tampering test asserts "unsigned", which holds trivially.

Full suite: 126 passed. tsc --noEmit and Prettier are clean.

Note on mcpb verify

Unrelated to this change and not addressed here: verifyMcpbFile calls node-forge's p7.verify(), which is a stub that throws PKCS#7 signature verification not yet implemented in both 1.3.3 and 1.4.0. It is caught and turned into {status: "unsigned"}, so mcpb verify reports "Extension is not signed" for every signed bundle and the digest comparison below it is unreachable. That is worth a separate fix.