amal66 gives uploads a reality check

This fork stops trusting a file's name and starts checking whether its contents match the claimed format.

securityintake

A document labelled as a PDF or Word file is no longer accepted on its extension alone. amal66 adds a content-level check at upload, looking for the identifying signature embedded in an actual file.

That is a small but meaningful hardening move. It reduces the chance that a disguised or malformed upload reaches a matter or project workspace simply because it has a familiar filename. The change is backed by focused tests, though teams adopting it should confirm that legitimate edge-case PDF and Word uploads still pass cleanly.

So what Legal teams handling client documents should care because safer intake starts before a file reaches review, search, or storage.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

1 commit from amal66/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
b358c585 fix(chapter-25): validate uploads by file signature Amal 2026-05-24 ↗ GitHub
commit body
Chapter: 25 - Upload trust boundary.

Plain-English map:
Check uploaded files by their magic bytes, not only by their filename or
extension.

Why it matters:
A file can be renamed to look harmless. The backend should inspect the actual
file signature before accepting it as a supported document type.

Principle:
Trust content, not labels.

Precedent borrowed:
Upstream PR #78 and standard upload-validation practice.

Upstream base: willchen96/mike@d39f580.
Original local commit: c6dd2ec.

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-2011.md from inside the repo you want the changes in.

⬇ Download capture-thread-2011.md