attachments: strip EXIF metadata from image attachments
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start by locating IncidentFile's add path and tracing how image bytes are stored and passed to sync and PDF generation. Check existing image-processing dependencies and tests; the issue gives no specific test file. Done means metadata is stripped on ingest across supported image formats while orientation is preserved, and merged PDF metadata remains out of scope unless inexpensive.
由索引模型根据 Issue 内容生成。
描述
What
Lagebuch does not strip EXIF metadata from attached images. A repo-wide search for exif over src/ returns nothing; image bytes go into the .files folder verbatim and into the PDF report verbatim.
Why it matters
A photo taken with a Diensthandy at the Einsatzstelle typically carries GPS coordinates, the exact capture timestamp, and the device model. All of that travels with the attachment: into the incident's .files folder, over the sync connection to every joined device, and into the exported PDF that goes to the Akte and the Kreisbrandinspektion.
The coordinates are usually the address of a private property, and often the address of the person whose name is already in the CO-Messprotokoll. Nothing about the app's UI suggests a photo carries anything beyond what is visible in it.
docs/datenschutz-und-sicherheit.md (#380) names this as a known limit, which is the honest short-term answer, but stripping is the right one.
Shape
Strip on ingest, in IncidentFile's add path, so it applies uniformly to the local store, the sync payload and the PDF — rather than at export, which would leave the stored copy untouched.
Decide deliberately what to keep: orientation must survive or photos display rotated. Everything else (GPS, timestamps, device, serial numbers, thumbnails — which can themselves contain a pre-edit image) can go.
PNG/WebP/GIF carry metadata chunks too and should be handled in the same pass. Merged PDF attachments have their own metadata; out of scope here unless it is cheap.
- 主要语言
- C#
- 星标
- 1
- 派生
- 3
- 平均合并
- 4 小时 15 分钟
- 30 天内合并 PR
- 181
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
CodeForFire/lagebuch 的其他 Issue
-
Stammdaten: in the Checkliste editor the PFLICHT header is not aligned with its column可能已有人在做 @Saad-elnagar 于 2 天前认领。 未关闭bug ux
难度 2/5 1-3 小时 新手友好度 78/100
CodeForFire/lagebuch#714 · 1 条评论 ·
维护者通常 1 天内回复
-
Stammdaten: on a phone the Fahrzeuge editor squeezes Wache and Funkrufname to nothing可能已有人在做 @Saad-elnagar 于 2 天前认领。 未关闭bug ux
难度 2/5 1-3 小时 新手友好度 75/100
CodeForFire/lagebuch#713 · 1 条评论 ·
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 62/100
CodeForFire/lagebuch#405 ·
维护者通常 1 天内回复
-
documentation good first issue
难度 2/5 1-3 小时 新手友好度 88/100
CodeForFire/lagebuch#349 ·
维护者通常 1 天内回复
-
documentation good first issue
难度 2/5 1-3 小时 新手友好度 88/100
CodeForFire/lagebuch#348 ·
维护者通常 1 天内回复
查看 CodeForFire/lagebuch 的全部 Issue
相似的 Issue
-
alerts bug effort:S P2
难度 2/5 1-3 小时 新手友好度 76/100
nightscout/nocturne#2511 ·
维护者通常 1 天内回复
-
feature-request
难度 2/5 1-3 小时 新手友好度 77/100
stripe/stripe-dotnet#3484 ·
维护者通常 2 天内回复
-
bug mcp misleading small
难度 2/5 1-3 小时 新手友好度 77/100
维护者通常 1 天内回复
-
accessibility help wanted macos
难度 2/5 1-3 小时 新手友好度 70/100
dorlugasigal/annotator#42 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 75/100
AvaloniaUI/Avalonia#22568 ·
维护者通常 2 天内回复