[Feature] Document the memory-safety mitigations for the native layer (QA.05) #553

New issue

Closed

opened 2026-07-22 13:44:01 +00:00 by brenno · 0 comments

brenno commented

2026-07-22 13:44:01 +00:00

Owner

The tempting answer is wrong. Dart is memory-safe, so it is easy to tick this box and move on. But opencv_core pulls in dartcv, which is C++, and it is the layer that decodes untrusted image data — the exact place where a malformed file becomes a memory-safety bug. #517 already named it: a full major version behind, the largest attack surface in the tree, held back by a constraint. That issue is closed on freshness; the mitigation story was never written down.

What we can honestly claim. Some of it exists and is simply undocumented:

Dart everywhere else, so the native surface is one dependency wide, not spread through the codebase.
Input validation before the native call — docs/SECURITY_DESIGN.md §6 describes it; the question is whether the image path actually passes through it before dartcv sees the bytes, and that needs checking rather than assuming.
The bounded-read work just merged (f5021502, #548) is precisely a memory-safety mitigation, even though it was not filed as one.
The scan only runs on decks that contain images — a scope limit, not a mitigation, but worth stating so the reader knows what triggers the layer.

What is missing. No fuzzing or malformed-input corpus against the decode path. No test asserting that a corrupt or hostile image fails closed instead of reaching the decoder. No written statement of what happens when the native layer crashes — does the app die, or does the slide simply not render?

Deliverable. A section in docs/SECURITY_DESIGN.md — it belongs beside §2 (supply-chain integrity) or §6 (input validation) — that names the non-memory-safe surface, lists the mitigations that actually exist with a pointer each, and says plainly what is not covered. Plus at least one regression test on the decode path with a malformed image, per the standing rule that a fix gets a test.

Only once that exists can QA.05 be ticked, and then it is ticked because it is true.

QA.05 of the light-weight attestation (#549) reads: if the project relies on code written in non-memory-safe languages, it must include mitigations for memory-safety vulnerabilities — minimum contribution guidelines, automated tests that changes do not introduce common memory-safety errors, that sort of thing. It maps to Annex I Part II.3. **The tempting answer is wrong.** Dart is memory-safe, so it is easy to tick this box and move on. But `opencv_core` pulls in `dartcv`, which is C++, and it is the layer that **decodes untrusted image data** — the exact place where a malformed file becomes a memory-safety bug. #517 already named it: a full major version behind, the largest attack surface in the tree, held back by a constraint. That issue is closed on freshness; the mitigation story was never written down. **What we can honestly claim.** Some of it exists and is simply undocumented: - **Dart everywhere else**, so the native surface is one dependency wide, not spread through the codebase. - **Input validation before the native call** — `docs/SECURITY_DESIGN.md §6` describes it; the question is whether the image path actually passes through it before `dartcv` sees the bytes, and that needs checking rather than assuming. - **The bounded-read work** just merged (f5021502, #548) is precisely a memory-safety mitigation, even though it was not filed as one. - **The scan only runs on decks that contain images** — a scope limit, not a mitigation, but worth stating so the reader knows what triggers the layer. **What is missing.** No fuzzing or malformed-input corpus against the decode path. No test asserting that a corrupt or hostile image fails closed instead of reaching the decoder. No written statement of what happens when the native layer crashes — does the app die, or does the slide simply not render? **Deliverable.** A section in `docs/SECURITY_DESIGN.md` — it belongs beside §2 (supply-chain integrity) or §6 (input validation) — that names the non-memory-safe surface, lists the mitigations that actually exist with a pointer each, and says plainly what is not covered. Plus at least one regression test on the decode path with a malformed image, per the standing rule that a fix gets a test. Only once that exists can QA.05 be ticked, and then it is ticked because it is true.

brenno added the

docs

triage

enhancement

labels

2026-07-22 13:44:01 +00:00

brenno referenced this issue from a commit

2026-07-22 15:40:44 +00:00

docs(security): beschrijf de niet-geheugenveilige laag, en meet wat hij doorlaat

brenno referenced this issue from a pull request that will close it,

2026-07-22 15:40:45 +00:00

docs: de CRA-attestatietros — rentmeester, EOL, feed, geheugenveiligheid, busfactor en COMPLIANCE.md #566