fix(uploads): normalize submitted images

[gouveags]

Summary

• make Sharp an explicit dependency and update it to 0.35.4
• decode and re-encode uploaded JPEG, PNG, and WebP files
• reject animated or multi-page image payloads and cap decoded pixels
• enforce the documented 10 MiB ceiling on both input and normalized output before storage
• preserve the active registration claimKey handling from current main

Problem

Magic-byte checks identify a file format but preserve embedded metadata and arbitrary trailing content. Re-encoding accepted images produces a clean canonical output before storage, but canonicalization can expand a valid sub-10-MiB input above the storage/resource limit unless the result is bounded too.

Validation

• npm ci
• npm run db:generate
• npm run db:migrate
• npm run check
• npx prisma validate
• npm audit (0 vulnerabilities)
• npm run build
• manual upload/resource and claim-preservation security review

Focused coverage proves arbitrary trailing bytes are removed, a sub-10-MiB noisy JPEG that expands above 10 MiB is rejected, animated WebP is rejected, and input above 25 million decoded pixels is rejected.

Scope

PDF payment proofs remain byte-validated but are not antivirus/CDR scanned; that requires an external scanning service or deployment component.

[gouveags]

@greptileai review

[gouveags]

Independent security review

Current state/checks: OPEN but currently CONFLICTING/DIRTY against main; the recorded Validar aplicação run passed on the original base and the PR-only AWS publish job was skipped. No unresolved review threads were present.

Actionable (blocking): src/lib/registration-upload.ts:4-10 re-encodes up to 25 million pixels at JPEG/WebP quality 90, but src/app/api/registrations/route.ts:60-70 applies the 10 MiB limit only to the untrusted input and never bounds the normalized output. A valid sub-10-MiB JPEG can expand beyond 10 MiB when re-encoded (for example, a noisy 5000×5000 quality-50 JPEG expands from about 9.1 MiB to 13.7 MiB), bypassing the documented per-file storage/resource ceiling. Check the resulting buffer against the limit (or resize/reduce quality deterministically) before writing, and add an expansion case.

Residual/informational: Single-page enforcement, decoded-pixel limiting, orientation, and re-encoding are sound defenses for accepted images; the test should also cover animation/pixel-limit rejection. PDF proofs remain signature-only and require the separately acknowledged scanning/CDR control. Reconcile #2 plus the shared route changes in #3/#4/#11, then rerun install/build/security checks on the production Linux target.

[gouveags]

Addressed the blocking upload-size finding in commit c4e2b54.

• merged current main and preserved the active registration claim-key handling
• enforce the same 10 MiB ceiling after Sharp normalization, before any write
• return a specific validation error when canonical output exceeds the limit
• added regression coverage for a sub-10-MiB JPEG that expands above 10 MiB, animated WebP rejection, and the 25-million-pixel ceiling

Validation passed locally after a clean install and current migrations: npm run check, npx prisma validate, npm audit (0 vulnerabilities), and npm run build. Manual security review found no unresolved issue in this diff; normalized content is rejected before storage, existing signature checks remain, and current claim safeguards are retained.