test+docs: bytecap en omleidingsweigering echt getoetst, projectiegrens-claim recht (#618, #601, #645) #654

Merged

brenno merged 2 commits from fix/media-cap-toetsbaar into main

2026-07-22 17:12:33 +00:00

brenno commented

2026-07-22 17:12:23 +00:00

Owner

Drie uit de review vóór publicatie, twee commits.

#618 — twee beloftes die alleen door commentaar bewaakt werden

SECURITY.md belooft allebei. De test die naar de bytecap heette deed expect(kMaxRemoteMediaBytes, greaterThan(0)) — een toets dát de constante bestaat, niet dat de grens werkt. De drie regels die hem uitoefenen hadden nul dekking; schrappen leverde een groene bouw op.

Zelfde onbereikbaarheid als eerder bij de CVE-download: guardedNetworkImageBytes pint de socket via NetGuard, en die weigert loopback, dus een testserver op deze machine bestaat per ontwerp niet. De grens staat nu apart in readCappedMedia juist zodat hij te bereiken is — inclusief het geval waar de tweede telling voor bestaat: een liegende of ontbrekende Content-Length. Ook de randen: precies op de grens mag nog, één byte erover niet.

De omleidingsweigering stond in network_sink_guard_test letterlijk als regel commentaar. Nu is het een assertie over elke gepinde client. Waarom het uitmaakt: volgt zo'n client zelf een 3xx, dan legt hij een níéuwe verbinding naar een adres dat nooit door de poort kwam — en dan was het pinnen voor niets. Alle zeven zetten hem vandaag, dus de lijst begint leeg.

Beide geplant en rood gezien.

#601 — de sterkste beveiligingszin op de voorpagina klopte half

De README zei dat het typesysteem de projectiegrens afdwingt "so no render surface can forget it".

De eerste helft klopt: het geredigeerde type heeft een private constructor, dus een oppervlak dat erom vraagt kán de rauwe bron niet krijgen. De gevolgtrekking klopt niet — de compiler weet niet wélke functies dat type horen te eisen, en juist daar zit het vergeten uitvoerkanaal. Dat is precies wat de poort uit #561 doet, en de kop van díé poort zegt het al met zoveel woorden.

De README zegt het nu ook, inclusief de blinde vlek (een oppervlak dat het schrijven twee lagen verderop uitbesteedt wordt niet gezien). Dit is de eerste zin die een security-reviewer natrekt; hij hoort te kloppen in plaats van indruk te maken. Het commentaar in privacy_projection.dart beweerde hetzelfde en is meegegaan.

#645 — het dode meldadres

Blijft staan in de CHANGELOG, want het wás de fout en correcties blijven hier staan. Maar er staat nu bij dat het níét in gebruik is, zodat grep -rn "security@" geen twee adressen oplevert zonder aanwijzing welk het huidige is.

make check groen.

Closes #618
Closes #601
Closes #645

Drie uit de review vóór publicatie, twee commits. ## #618 — twee beloftes die alleen door commentaar bewaakt werden `SECURITY.md` belooft allebei. De test die naar de bytecap heette deed `expect(kMaxRemoteMediaBytes, greaterThan(0))` — een toets dát de constante bestaat, niet dat de grens werkt. De drie regels die hem uitoefenen hadden nul dekking; schrappen leverde een groene bouw op. Zelfde onbereikbaarheid als eerder bij de CVE-download: `guardedNetworkImageBytes` pint de socket via NetGuard, en die weigert loopback, dus een testserver op deze machine bestaat per ontwerp niet. De grens staat nu apart in `readCappedMedia` juist zodat hij te bereiken is — inclusief het geval waar de tweede telling voor bestaat: een **liegende of ontbrekende Content-Length**. Ook de randen: precies op de grens mag nog, één byte erover niet. De omleidingsweigering stond in `network_sink_guard_test` letterlijk als regel commentaar. Nu is het een assertie over elke gepinde client. Waarom het uitmaakt: volgt zo'n client zelf een 3xx, dan legt hij een níéuwe verbinding naar een adres dat nooit door de poort kwam — en dan was het pinnen voor niets. Alle zeven zetten hem vandaag, dus de lijst begint leeg. Beide geplant en rood gezien. ## #601 — de sterkste beveiligingszin op de voorpagina klopte half De README zei dat het typesysteem de projectiegrens afdwingt "so no render surface can forget it". De eerste helft klopt: het geredigeerde type heeft een private constructor, dus een oppervlak dat erom vraagt kán de rauwe bron niet krijgen. **De gevolgtrekking klopt niet** — de compiler weet niet wélke functies dat type horen te eisen, en juist daar zit het vergeten uitvoerkanaal. Dat is precies wat de poort uit #561 doet, en de kop van díé poort zegt het al met zoveel woorden. De README zegt het nu ook, inclusief de blinde vlek (een oppervlak dat het schrijven twee lagen verderop uitbesteedt wordt niet gezien). Dit is de eerste zin die een security-reviewer natrekt; hij hoort te kloppen in plaats van indruk te maken. Het commentaar in `privacy_projection.dart` beweerde hetzelfde en is meegegaan. ## #645 — het dode meldadres Blijft staan in de CHANGELOG, want het wás de fout en correcties blijven hier staan. Maar er staat nu bij dat het níét in gebruik is, zodat `grep -rn "security@"` geen twee adressen oplevert zonder aanwijzing welk het huidige is. `make check` groen. Closes #618 Closes #601 Closes #645

brenno added 2 commits

2026-07-22 17:12:24 +00:00

test(netguard): toets de bytecap en de omleidingsweigering echt f87e207378

Twee publieke beloftes in SECURITY.md die alleen door commentaar bewaakt werden.

De test die naar de bytecap heette, deed `expect(kMaxRemoteMediaBytes,
greaterThan(0))` — een toets dat de constante bestaat, niet dat de grens werkt.
De drie regels die hem uitoefenen hadden nul dekking. Schrap ze en er werd niets
rood.

Dezelfde onbereikbaarheid als eerder bij de CVE-download: guardedNetworkImage
Bytes pint de socket via NetGuard, en die weigert loopback, dus een testserver
op deze machine bestaat per ontwerp niet. De grens staat nu apart in
`readCappedMedia`, juist zodat hij te bereiken is — inclusief het geval waar de
tweede telling voor bestaat: een liegende of ontbrekende Content-Length.

De omleidingsweigering stond letterlijk als regel commentaar. Nu is het een
assertie over elke gepinde client: volgt er één een 3xx, dan legt hij een
níéuwe verbinding naar een adres dat nooit gekeurd is, en was het pinnen voor
niets. Alle zeven zetten hem vandaag, dus de lijst begint leeg.

Beide geplant en rood gezien.

Closes #618

docs: corrigeer de projectiegrens-claim, en markeer het dode meldadres

CI / Web hardening (push) Failing after 10s

Details

CI / Gate (Linux) · Format · Analyze · Coverage (push) Failing after 11s

Details

CI / Docs links (push) Failing after 9s

Details

CI / Supply-chain (Trivy · advisory) (push) Failing after 10s

Details

CI / Gate (Linux) · Format · Analyze · Coverage (pull_request) Failing after 10s

Details

CI / Web hardening (pull_request) Failing after 11s

Details

CI / Docs links (pull_request) Failing after 11s

Details

CI / Supply-chain (Trivy · advisory) (pull_request) Failing after 12s

Details

CI / Test (macos-latest) (push) Has been cancelled

Details

CI / Test (windows-latest) (push) Has been cancelled

Details

CI / Test (macos-latest) (pull_request) Has been cancelled

Details

CI / Test (windows-latest) (pull_request) Has been cancelled

Details

bf16eaa9c8

#601 — de README zei dat het typesysteem de projectiegrens afdwingt "so no
render surface can forget it". De eerste helft klopt: het geredigeerde type
heeft een private constructor, dus een oppervlak dat erom vraagt kán de rauwe
bron niet krijgen. De gevolgtrekking klopt niet — de compiler weet niet wélke
functies dat type horen te eisen, en juist dáár zit een vergeten uitvoerkanaal.

Dat is precies wat de poort uit #561 doet, en de kop van die poort zegt het
zelf. De README zegt het nu ook, inclusief de blinde vlek. Dit is de sterkste
beveiligingszin op de voorpagina en de eerste die een reviewer natrekt; hij
hoort te kloppen in plaats van indruk te maken. Het commentaar in
privacy_projection.dart beweerde hetzelfde en is meegegaan.

#645 — het dode adres security@vigilis.nl staat in de CHANGELOG omdat het de
fout wás, en correcties blijven hier staan. Maar er staat nu bij dat het níét
in gebruik is, zodat een grep geen twee adressen oplevert zonder aanwijzing
welk het huidige is.

Closes #601
Closes #645