harden: validate PE output and timestamp tokens

[Loggableim]

What changed

• Reject PE certificate tables whose range is outside the input buffer.
• Validate the outer CMS SignedData structure of RFC3161 timestamp tokens before embedding.
• Publish signed outputs through synced same-directory temp files, preserve destination permissions, atomically replace outputs, and never clobber an existing .orig backup.

Explicitly excluded

No timestamp transport-policy change: no --allow-insecure-timestamp, HTTP rejection, Content-Type enforcement, CI, or documentation changes.

[Le-Syl21]

This is good work — all three items I asked for, and the excluded list matches exactly what I said I didn't want to take. Thanks for keeping the scope tight.

The atomic write path is solid. Creating the temp with create_new gives you O_EXCL, so the predictable name isn't a problem; keeping it in the destination directory is what makes the rename atomic; and publishing the backup before the replace is the right order — if .orig is already there we fail without having touched the original. Using hard_link to get "never clobber" is neat, it fails on an existing destination without a check-then-act race.

Two things.

The bounds check is stricter than it needs to be when the table is empty. It runs before the branch that special-cases a zero-length table:

if l.cert_table_off > pe.len() || cert_end > pe.len() { bail!(...) }
let (cert_start, cert_end) = if l.cert_table_size == 0 {
    (pe.len(), pe.len())        // offset is not used here
} else { ... };

With cert_table_size == 0, cert_end == cert_table_off, so the guard rejects on an offset the code then ignores. A PE that was signed and later stripped can carry a stale offset with a zero size — that hashed fine before and would now be refused. Moving the check into the else branch keeps the protection where it matters. Your test uses size = 0x20, so it doesn't cover this case; a zero-size one with a garbage offset would be worth adding.

The Windows atomic_replace is untested. The flags and the MoveFileExW signature look right to me, but it's hand-rolled FFI and the test only exercises the Unix path, so nothing verifies it. Not a blocker — just flagging that it ships unexercised.

Minor, take it or leave it: there's no directory fsync after the rename. That doesn't affect the failure you're fixing (a process dying mid-write), only durability across a power loss.

Fix the first point and I'll merge this.