feat(signature): prototype cryptographic signature renderer - #214
feat(signature): prototype cryptographic signature renderer#214p4535992 wants to merge 9 commits into
Conversation
Add @file-viewer/renderer-signature registration and dependency to web-full and all preset packages, import signatureRenderer, include it in the allRenderers list, and add the corresponding test script.
Preserve the DSS/signature renderer integration while incorporating flyfish-dev/file-viewer main through 9bfed4c. Overlapping manifests are aligned to workspace 2.4.0 and pnpm-lock.yaml keeps the upstream lock with only the 16 signature importer/dependency lines added.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0214e7ab2b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const hash = digestNameForOid(hashOid); | ||
| try { | ||
| if ( | ||
| certificate.publicKeyAlgorithmOid === OID.rsaEncryption || |
There was a problem hiding this comment.
For CMS signatures using RSA-PSS, the signer certificate normally has the generic rsaEncryption public-key OID, so this condition selects the PKCS#1 v1.5 branch and returns before the rsaPss branch below can run. Valid RSA-PSS signatures are therefore reported as cryptographically invalid; dispatch on signatureOid === OID.rsaPss before using the certificate key type as the generic RSA fallback.
Useful? React with 👍 / 👎.
| "@file-viewer/renderer-ofd": "workspace:2.4.0", | ||
| "@file-viewer/renderer-pdf": "workspace:2.4.0", | ||
| "@file-viewer/renderer-presentation": "workspace:2.4.0", | ||
| "@file-viewer/renderer-signature": "workspace:2.4.0", |
There was a problem hiding this comment.
Adding this dependency exposes signature support through the ESM preset, but the CDN/IIFE path maintains separate tables in packages/components/web-full/src/iife.ts (lazyRendererLines) and scripts/build-iife.mjs (rendererBuilds), neither of which contains signature. Consequently the published web-full IIFE neither builds a signature renderer bundle nor maps .p7m/.p7s/timestamp/OpenPGP extensions to one, so those files remain unsupported in that advertised full-package deployment.
Useful? React with 👍 / 👎.
| id: 'signature', | ||
| label: 'Digital signature and timestamp', | ||
| category: 'document', | ||
| extensions: ['p7m', 'p7s', 'p7b', 'p7c', 'pkcs7', 'cms', 'cmsc', 'tsq', 'tsr', 'tst', 'tsd', 'asc', 'sig', 'pgp', 'gpg'], |
There was a problem hiding this comment.
When an application configures @file-viewer/vite-plugin with one of these new formats (for example formats: ['p7m']) instead of the whole all preset, selectRenderers reports that no mapping is registered because packages/presets/vite-plugin/src/index.ts has no signature entry in rendererModules. The virtual module therefore never imports this renderer; add a descriptor covering the signature renderer ID and its extensions.
Useful? React with 👍 / 👎.
| pub max_packet_count: usize, | ||
| pub max_nesting_depth: usize, | ||
| pub max_user_ids: usize, | ||
| pub max_subkeys: usize, | ||
| pub max_signatures: usize, |
There was a problem hiding this comment.
For hostile or caller-constrained OpenPGP input, maxPacketCount, maxNestingDepth, and maxSignatures have no effect: a repository-wide search shows these fields are only declared here, while validation checks only input byte length and inspection passes the input directly to rPGP. Thus even overrides such as maxPacketCount: 1 are ignored and the Worker can spend unbounded structural parsing work within the 32 MiB input allowance; enforce these limits during packet traversal or remove the unsupported controls and bounded-inspection claim.
Useful? React with 👍 / 👎.
1 participant
DIRTY PR TO IGNORE