Repository navigation
fixture: bundles are not safe to share — device_id / mac_address are never redacted #59
Description
capcut fixture --out <dir> is documented as producing a "shareable, redacted" bundle, and the generated README.md invites attaching it to a version-support issue. It does redact home paths and email addresses, but it never touches the device identifiers that CapCut stores in every timeline file.
What survives
The platform and last_modified_platform blocks are copied verbatim, so the bundle carries:
device_id— a stable 32-hex device identifiermac_address— likewise present as a 32-hex valuehard_disk_id— empty in my case, but not redacted, so it would survive where populated
These appear in draft_info.json, template-2.tmp, and in every Timelines/*/draft_info.json included in the bundle.
Separately, SANITIZE_REPORT.json records source_dir and out_dir as raw absolute paths. Those are not passed through the redactor, so the report re-introduces the username that the timeline files just had scrubbed.
Cause
The redactor list in src/fixture.ts has five entries:
windows_user, windows_user_fwd, macos_user, linux_user, email
All five are path- or email-shaped. Nothing matches a key inside platform, and SANITIZE_REPORT.json is written after redaction rather than through it.
Suggested fix
- Blank
device_id,mac_addressandhard_disk_idwherever they appear (platform,last_modified_platform, and any nested timeline copy).app_idmay be worth considering too. - Run the path redactor over
SANITIZE_REPORT.json's ownsource_dir/out_dir. - Count these in the per-file
redactionstotals, so the report reflects what was actually removed.
Why it matters
The documented flow for helping with version support is "run capcut fixture and attach the bundle". Anyone following it publishes device identifiers to a public issue while believing the bundle was sanitised — the filename and the report both say it was. I found this while preparing an 8.5.0 bundle and have held it back until the redactor is fixed.
No sample data is attached deliberately: demonstrating this bug should not require anyone to publish the identifiers it leaks. It reproduces on any CapCut-authored draft — inspect platform in the bundle output and compare against the source.
Activity
test(fixture): make the #59 path-redaction assertions platform-aware
fix(fixture): redact device identifiers from shared bundles (#66)
renezander030 commentedon Aug 9, 2026
Fixed and merged — #66, squashed to
07920ab3fonmaster.Your report was accurate on all three points. For the record, verified against the code before changing anything:
REDACTORSinsrc/fixture.tshad exactly the five path/email entries you listed;device_id,mac_addressandhard_disk_idhad zero occurrences anywhere insrc/— nothing touched them;SANITIZE_REPORT.jsonwas written after redaction withsource_dir/out_dirstraight fromstore.projectDir, so it put the username back.What landed:
device_idandmac_addressare plain 32-hex, and a bare/[0-9a-f]{32}/would also have blanked legitimate material and segment UUIDs. It handles the escaped-quote formtemplate-2.tmpuses for its string-JSON, and covers the nestedTimelines/*/draft_info.jsoncopies;hard_disk_idis not reported as something that was removed — theredactionstotals reflect what actually went;source_dirandout_dirnow go through the redactor;Regression coverage includes a sweep asserting no identifier survives in any emitted file, the report and README included. That also confirmed
diagnose.jsonwas never a second leak path.One deliberate omission:
app_idis left alone. It identifies the app build rather than the machine, and nothing insrc/reads it. Say the word if you'd rather it went too.Not in a published release yet — latest is v0.17.2 from 8 Aug, which predates this. It'll go out with the next one; until then it needs a build from
master.Your three other findings are also fixed: #60 is split into #67 (init template rejected by 8.5.0), #68 (nested-Timelines guidance now version-gated) and #69 (frame-quantisation docs), all merged.
An 8.5.0 bundle would be genuinely useful whenever you get to it — #68's 8.5.0 branch currently rests on your report alone, which is the same report-only footing #50 has for 7.x. Thanks for holding it back rather than hand-sanitising; that was the right call and it's what made this worth fixing properly.
release: v0.18.0 (#74)
release: v0.20.0 — styled subtitles both ways, and the recording pipe…
release: v0.21.0 — nine opportunity-mined items (the #50 repair path,…