🐛 extractSignature: read DER length instead of stripping trailing 00 pairs (fixes #317)

[razortrax]

Problem

extractSignature() strips the placeholder padding with:

.replace(/(?:00|>)+$/, '');

The regex cannot distinguish sign()'s zero-padding from a genuine signature whose last byte(s) happen to be 0x00. A PKCS#7 SignedData's final bytes are the raw RSA signature — effectively random — so ~1/256 signatures genuinely end in 0x00. When one does, the strip eats real DER bytes and downstream parsers throw Too few bytes to read ASN.1 value. on a perfectly valid signature.

Full analysis in #317. We hit this as an intermittent (~0.4%) verification failure in CI; reproduced 9 truncations in 1500 sign/extract cycles against @signpdf/utils 3.x.

Fix

DER is self-describing: read the total element length from the SEQUENCE header (short- and long-form lengths supported) and slice there — exactly the direction suggested in #317. If the blob does not parse as a DER SEQUENCE, fall back to the historical trailing-zero strip so non-DER edge cases keep their previous behavior.

Also, the slice-then-strip previously relied on the regex to remove the trailing >; the hex cleanup now strips only > and whitespace before decoding.

Tests

• New: genuine trailing 0x00 byte is kept (short-form DER, the extractSignature(): trailing-zero regex strip can truncate a genuine signature byte (~1/256 chance), corrupting DER #317 scenario)
• New: long-form-length DER ending in 0x00 with padding is trimmed correctly
• New: unpadded signature is returned unchanged
• Existing signed.pdf snapshot unchanged; full monorepo lerna run test green (63/63 in utils)

🤖 Generated with Claude Code

[Copilot]

The job was not started because the account is locked due to a billing issue.