File Metadata Checklist for Open Source Maintainers
Cutting a release means bundling more than code. Screenshots for the README, a logo, sample input files for the test suite, a PDF of the design doc — all of it ships into a public repo, and once it's tagged, it's permanent. Unlike code review, nobody reads the hidden bytes of an image before it goes out. That's exactly where metadata slips through.
Why maintainers specifically should care
A personal repo with a stray device name in a screenshot is a minor annoyance. A popular open-source project is a different scale: thousands of people clone the history, forks propagate the files, and mirrors cache everything. If a contributor's screenshot has a GPS tag, a local file path, or an internal hostname baked into its metadata, it's now distributed indefinitely — and a `git rm` in a later commit doesn't undo it. The blob is still reachable in history unless someone rewrites it, which breaks every existing clone's object hashes.
This is also a trust issue. Projects that casually leak contributor details erode confidence quickly, especially in security-sensitive tooling where users expect maintainers to practice what they preach.
What actually rides along in release assets
- EXIF / XMP / IPTC — screenshot and editing tools write device names, software signatures, sometimes GPS if a photo made it into docs.
- Appended data — extra bytes left behind by annotation or compression tools.
- Zero-width characters and homoglyphs — if docs or READMEs were drafted with help from an AI writing tool and pasted in, invisible characters or look-alike letters can come along for the ride.
- PDF and Office docs in the repo — design docs, spec PDFs, or `.docx` files can carry author names and revision history in their own metadata. scrub can scan these and tell you what's there, but cleaning PDFs and Office files isn't supported yet — treat a flagged file as something to re-export or rebuild from a clean source, not something to run through a cleaner.
A pre-release checklist
- Scan new binary assets before mergingScreenshots, logos, sample images — check each one with scrub before it lands in a PR, not after.
- Clean what scrub can cleanImages get a lossless, metadata-stripped copy in seconds. Commit that copy.
- Flag what it can'tPDFs and Office docs get scanned, not cleaned. If one shows hidden content, re-export it from the original source without the sensitive fields.
- Make it a habit, not a one-offNew contributors won't know this by default — a line in CONTRIBUTING.md about checking images before a PR goes a long way.
None of this touches your source code — scrub runs entirely on your own machine, on the binary assets you point it at.
The short version
A repo's history is forever, so check images and docs for hidden metadata before you merge, not after. Clean what can be cleaned; for PDFs and Office files, scan first and re-export from source if something shows up. See also: removing metadata before uploading to GitHub and checking PDFs and Word docs for hidden data. Get scrub free and run it before your next release.