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

Merged

brenno merged 5 commits from docs/cra-rentmeester into main 2026-07-22 15:40:55 +00:00

Conversation 0 Commits 5 Files changed 10 +636 -2

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

Owner

Copy link

Zes issues uit de CRA/attestatie-tros, in de volgorde die ze zelf voorschrijven.
make check groen.

#550 — de rentmeestervraag (eerst, want die bepaalt wat AU.01 mag zeggen)

Het argument waarop de vraag gesteld was — OciDeck richt zich op pentesters, en
dat is commercieel werk — houdt geen stand. "Bestemd voor commerciële
activiteiten" gaat over de aanbodkant. De ORC WG werkt dat expliciet uit: een
project mag miljoenen gebruikers hebben, ook in ondernemingen en vitale
infrastructuur, zonder onder de verordening te vallen, zolang er niet
gemonetiseerd wordt.

Er staat toch "waarschijnlijk geen" en geen "nee". Overweging 19 noemt
uitdrukkelijk stichtingen, en de bronnen zeggen zélf dat het open staat: de
FAQ-ingang over rechtspersonen wacht op verduidelijking door de Commissie, en de
whitepaper over rentmeesters onthoudt zich uitdrukkelijk van een oordeel over wie
er één is. Stelligheid die de werkgroep zelf niet heeft, hoort hier niet.

De echte leemte staat erbij: van de vier verplichtingen uit artikel 24 hebben
we er drie. De melding aan CSIRT/ENISA bestaat niet — geen route, en niet eens
opgeschreven welk CSIRT het zou zijn. Klein om te repareren, en te laat als je
het uitzoekt op het moment dat er iets actief misbruikt wordt.

Over de bronnen. EUR-Lex serveert achter een botmuur een lege 202. Die heb ik
niet omzeild. De artikel- en overwegingsnummers komen daarom uit orcwg/cra-hub
en orcwg/orcwg (lokaal gekloond en gelezen op 2026-07-22), en dat staat zo in
de commit — niet weggepoetst.

#551 + #552 — einde van leven, en iets om je op te abonneren

De hele repo noemde het woord "end-of-life" niet. Er staat nu: wat "supported"
vandaag betekent, waar een stopzetting wordt aangekondigd, drie maanden
aanzegtermijn, en dat meldingen daarna niet meer beantwoord worden. Dat laatste
is de kern — een onbeheerd project dat nog wél meldingen aanneemt, is erger dan
een dat zegt van niet.

De drie maanden zijn gekozen op wat één beheerder kan waarmaken. Een ruimere
belofte bij een busfactor van één is een belofte over iemands toekomstige
omstandigheden.

Voor de feed: nagemeten, niet aangenomen. De forge serveert er drie —
releases.rss (leeg), tags.rss (alleen de archieftag) en de activiteitenfeed
(alles, en dus ruis). commits/branch/main.rss geeft 404. De lege releasefeed is
juist de aanbevolen: de dag dat er iets in staat, is dat een release.

Bewust geen mailinglijst — een abonneelijst is persoonsgegevens die wij dan
houden en ooit moeten wissen; een feed is een bestand op een server. Bij wat dit
project over gegevens belooft, beslist die asymmetrie het.

FAQ.md en MIGRATION_GUIDE.md spraken dit tegen ("geen mailinglijst, punt");
allebei gecorrigeerd met datum.

#553 — de niet-geheugenveilige laag, en wat hij werkelijk doorlaat

De maatregelen bleken beter dan de issue aannam: er staat al een poort vóór
cv.imdecode die alléén de kop leest, met een pixelgrens die de bestandsgrens
níet kan vervangen (een egale PNG van 30000×30000 is <1 MB op schijf en 2,7 GB in
het geheugen, buiten de Dart-heap, waar een try niet bij kan). Dat stond
nergens opgeschreven.

Wat nieuw is, is gemeten, en het corrigeerde mijn eigen aanname onderweg:

• een afgekapt bestand komt er in geen enkel formaat door, ook niet op 4 KiB —
  ruim voorbij de plek waar de afmetingen staan;
• een verminkte PNG evenmin (CRC per chunk + verplichte IEND);
• een verminkte JPEG kómt er wél doorheen, want de SOF draagt de afmetingen
  zonder checksum. Díe bytes gaan de C++-decoder in.

Dat laatste is geen gat maar de eerlijke vorm van de maatregel: de poort begrenst
de allocatie, niet de inhoud. De regressietest legt beide kanten vast,
inclusief de JPEG die er bewust wél doorheen moet — draait iemand dat ooit
stilletjes om, dan verandert welke bytes de native laag bereiken.

Met DARTCV_LIB_PATH gezet draaien deze tests écht door de C++-decoder: 19
groen, en de verminkte JPEG komt onleesbaar terug in plaats van om te vallen.

#554 — de busfactor

Eén actieve beheerder, zelf mergen, geen CI-runner. Opgeschreven in plaats van
stil overgeslagen, mét wat er wél voor staat — en met de zin die het verschil
maakt: een machine beoordeelt wat een machine kan beoordelen, en merkt niet dat
een ontwerp verkeerd is. De asymmetrie loopt één kant op: een binnengekomen PR
wordt wél door een niet-auteur bekeken.

#549 — de attestatie zelf

Drie regels niet aangevinkt, en dat is het punt van het document. Onderaan staat
"waar dit het zwakst is", te lezen vóór je besluit hierop te bouwen.

Twee claims onderweg gecorrigeerd omdat ze niet klopten. De termijnen
(5/10/90) staan in tool/check_service_norms.dart en niet in SECURITY.md; ze
staan er nu bij als "wat wij meten", uitdrukkelijk niet als toezegging aan een
melder. En het adres van de stichting verzin ik niet — dat veld verwijst naar de
eigen registratie. Dat veld wil je waarschijnlijk zelf invullen.

Er hoort een poort bij, want dit is het document dat het stilst veroudert:
elke verwijzing moet bestaan, het meldadres moet gelijk zijn aan dat in
SECURITY.md, en QA.06/QA.07 mogen niet ongemerkt aangevinkt raken. In drie
richtingen geplant en afgegaan.

Closes #549
Closes #550
Closes #551
Closes #552
Closes #553
Closes #554

Zes issues uit de CRA/attestatie-tros, in de volgorde die ze zelf voorschrijven. `make check` groen. ## #550 — de rentmeestervraag (eerst, want die bepaalt wat AU.01 mag zeggen) Het argument waarop de vraag gesteld was — OciDeck richt zich op pentesters, en dat is commercieel werk — houdt geen stand. "Bestemd voor commerciële activiteiten" gaat over de aanbodkant. De ORC WG werkt dat expliciet uit: een project mag miljoenen gebruikers hebben, ook in ondernemingen en vitale infrastructuur, zonder onder de verordening te vallen, zolang er niet gemonetiseerd wordt. Er staat toch "waarschijnlijk geen" en geen "nee". Overweging 19 noemt uitdrukkelijk stichtingen, en de bronnen zeggen zélf dat het open staat: de FAQ-ingang over rechtspersonen wacht op verduidelijking door de Commissie, en de whitepaper over rentmeesters onthoudt zich uitdrukkelijk van een oordeel over wie er één is. Stelligheid die de werkgroep zelf niet heeft, hoort hier niet. **De echte leemte staat erbij:** van de vier verplichtingen uit artikel 24 hebben we er drie. De melding aan CSIRT/ENISA bestaat niet — geen route, en niet eens opgeschreven welk CSIRT het zou zijn. Klein om te repareren, en te laat als je het uitzoekt op het moment dat er iets actief misbruikt wordt. **Over de bronnen.** EUR-Lex serveert achter een botmuur een lege 202. Die heb ik niet omzeild. De artikel- en overwegingsnummers komen daarom uit `orcwg/cra-hub` en `orcwg/orcwg` (lokaal gekloond en gelezen op 2026-07-22), en dat staat zo in de commit — niet weggepoetst. ## #551 + #552 — einde van leven, en iets om je op te abonneren De hele repo noemde het woord "end-of-life" niet. Er staat nu: wat "supported" vandaag betekent, waar een stopzetting wordt aangekondigd, drie maanden aanzegtermijn, en dat meldingen daarna niet meer beantwoord worden. Dat laatste is de kern — een onbeheerd project dat nog wél meldingen aanneemt, is erger dan een dat zegt van niet. De drie maanden zijn gekozen op wat één beheerder kan waarmaken. Een ruimere belofte bij een busfactor van één is een belofte over iemands toekomstige omstandigheden. Voor de feed: **nagemeten, niet aangenomen.** De forge serveert er drie — `releases.rss` (leeg), `tags.rss` (alleen de archieftag) en de activiteitenfeed (alles, en dus ruis). `commits/branch/main.rss` geeft 404. De lege releasefeed is juist de aanbevolen: de dag dat er iets in staat, is dat een release. Bewust geen mailinglijst — een abonneelijst is persoonsgegevens die wij dan houden en ooit moeten wissen; een feed is een bestand op een server. Bij wat dit project over gegevens belooft, beslist die asymmetrie het. `FAQ.md` en `MIGRATION_GUIDE.md` spraken dit tegen ("geen mailinglijst, punt"); allebei gecorrigeerd met datum. ## #553 — de niet-geheugenveilige laag, en wat hij werkelijk doorlaat De maatregelen bleken beter dan de issue aannam: er staat al een poort vóór `cv.imdecode` die alléén de kop leest, met een pixelgrens die de bestandsgrens níet kan vervangen (een egale PNG van 30000×30000 is <1 MB op schijf en 2,7 GB in het geheugen, buiten de Dart-heap, waar een `try` niet bij kan). Dat stond nergens opgeschreven. Wat nieuw is, is **gemeten**, en het corrigeerde mijn eigen aanname onderweg: - een afgekapt bestand komt er in geen enkel formaat door, ook niet op 4 KiB — ruim voorbij de plek waar de afmetingen staan; - een verminkte PNG evenmin (CRC per chunk + verplichte IEND); - **een verminkte JPEG kómt er wél doorheen**, want de SOF draagt de afmetingen zonder checksum. Díe bytes gaan de C++-decoder in. Dat laatste is geen gat maar de eerlijke vorm van de maatregel: de poort begrenst de *allocatie*, niet de *inhoud*. De regressietest legt beide kanten vast, inclusief de JPEG die er bewust wél doorheen moet — draait iemand dat ooit stilletjes om, dan verandert welke bytes de native laag bereiken. Met `DARTCV_LIB_PATH` gezet draaien deze tests écht door de C++-decoder: 19 groen, en de verminkte JPEG komt onleesbaar terug in plaats van om te vallen. ## #554 — de busfactor Eén actieve beheerder, zelf mergen, geen CI-runner. Opgeschreven in plaats van stil overgeslagen, mét wat er wél voor staat — en met de zin die het verschil maakt: een machine beoordeelt wat een machine kan beoordelen, en merkt niet dat een ontwerp verkeerd is. De asymmetrie loopt één kant op: een binnengekomen PR wordt wél door een niet-auteur bekeken. ## #549 — de attestatie zelf Drie regels niet aangevinkt, en dat is het punt van het document. Onderaan staat "waar dit het zwakst is", te lezen vóór je besluit hierop te bouwen. **Twee claims onderweg gecorrigeerd omdat ze niet klopten.** De termijnen (5/10/90) staan in `tool/check_service_norms.dart` en *niet* in `SECURITY.md`; ze staan er nu bij als "wat wij meten", uitdrukkelijk niet als toezegging aan een melder. En het adres van de stichting verzin ik niet — dat veld verwijst naar de eigen registratie. **Dat veld wil je waarschijnlijk zelf invullen.** Er hoort een poort bij, want dit is het document dat het stilst veroudert: elke verwijzing moet bestaan, het meldadres moet gelijk zijn aan dat in `SECURITY.md`, en QA.06/QA.07 mogen niet ongemerkt aangevinkt raken. In drie richtingen geplant en afgegaan. Closes #549 Closes #550 Closes #551 Closes #552 Closes #553 Closes #554

brenno added 5 commits 2026-07-22 15:40:45 +00:00

docs(cra): beslis de rentmeestervraag, en zeg erbij hoe zeker dat is ... 2b9c64730a

Het besluit besliste "geen fabrikant" en zweeg over de andere rol die de
verordening kent. Die stilte werd dragend: een vrijwillige attestatie moet in
AU.01 zeggen wát de uitgevende partij is, en "een stichting, maar geen
rentmeester" is een bewering en geen leeg vakje.

Het argument waarop de vraag gesteld was — OciDeck richt zich op pentesters, en
dat is commercieel werk — houdt geen stand. "Bestemd voor commerciële
activiteiten" gaat over de aanbodkant. De ORC WG werkt dat expliciet uit: een
project mag miljoenen gebruikers hebben, ook in ondernemingen en vitale
infrastructuur, zonder onder de verordening te vallen, zolang er niet
gemonetiseerd wordt. Commercieel gebruik is geen commerciële levering.

Toch staat er "waarschijnlijk" en geen "nee". Overweging 19 noemt uitdrukkelijk
stichtingen, en de bronnen zeggen zelf dat het open staat: de FAQ-ingang over
rechtspersonen wacht op verduidelijking door de Commissie, en de whitepaper over
rentmeesters onthoudt zich uitdrukkelijk van een oordeel over wie er één is.
Stelligheid die de werkgroep zelf niet heeft, hoort hier niet.

De echte leemte staat erbij: van de vier verplichtingen uit artikel 24 hebben we
er drie, en de melding aan CSIRT/ENISA bestaat niet — geen route, en niet eens
opgeschreven welk CSIRT het zou zijn. Klein om te repareren, en te laat als je
het uitzoekt op het moment dat er iets actief misbruikt wordt.

Zesde kantelmoment toegevoegd.

Bronnen nagelezen op 2026-07-22 in orcwg/cra-hub en orcwg/orcwg (FAQ + whitepaper
rentmeesters). De verordeningstekst zelf staat op EUR-Lex achter een botmuur die
een lege 202 teruggeeft; de artikel- en overwegingsnummers komen daarom uit die
FAQ en niet uit het Publicatieblad. Dat is genoteerd, niet weggepoetst.

Closes #550

docs(security): zeg wat er gebeurt als dit project stopt, en wat je kunt volgen ... 51331d1238

Twee dingen die een buitenstaander als eerste zoekt en die hier nergens stonden.

**Einde van leven (EL.01).** De hele repo noemde het woord niet. Een
ondersteuningstabel met versies zou theater zijn — die zijn er niet — maar wat
er wél te zeggen valt is waar en wanneer een stopzetting wordt aangekondigd, dat
er drie maanden tussen zit, en dat meldingen daarna niet meer worden beantwoord.
Dat laatste is de kern: een onbeheerd project dat nog wél meldingen aanneemt is
erger dan een dat zegt van niet. Het slot is archiveren en niet verwijderen, en
dat is dezelfde belofte als platte Markdown: je werk moet het gereedschap kunnen
overleven.

De drie maanden zijn gekozen op wat één beheerder kan waarmaken. Een ruimere
belofte bij een busfactor van één is een belofte over iemands toekomstige
omstandigheden, en die maakt dit bestand niet.

**Iets om je op te abonneren.** De verklaring "geen forum, geen mailinglijst"
klopt voor ondersteuning en was fout voor beveiliging: een gerepareerd lek is
push, geen pull. De forge blijkt drie feeds te serveren — nagemeten, niet
aangenomen: releases (leeg), tags (alleen de archieftag) en de activiteitenfeed
(alles, en dus ruis). De lege releasefeed is juist de aanbevolen: de dag dat er
iets in staat, is dat een release.

Bewust geen mailinglijst. Een abonneelijst is persoonsgegevens die wij dan
houden, beschermen en ooit moeten wissen; een feed is een bestand op een server.
Bij wat dit project over gegevens belooft, beslist die asymmetrie het.

Een beveiligingsregel in de CHANGELOG begint voortaan met `Security:` — een feed
helpt alleen als het item herkenbaar is.

FAQ.md en MIGRATION_GUIDE.md spraken dit tegen; beide gecorrigeerd met datum.

Closes #551
Closes #552

docs(contributing): noem de busfactor van één, en wat er wél voor staat ... 7dcbcfb2cd

QA.06 en QA.07 van de lichte attestatie zijn de twee die niet aangevinkt kunnen
worden, en allebei gaan ze over mensen in plaats van code. Ze worden hier
opgeschreven in plaats van stil overgeslagen: een checklist die zijn zwakste
regel verbergt, leert de lezer de regels te wantrouwen die wél kloppen.

Eén actieve beheerder, zelf mergen, geen CI-runner. Dat is het grootste risico
in dit project — groter dan wat een scanner ooit heeft gemeld.

Wat ervoor in de plaats staat, staat er precies zo bij, want het is niet niets
én het is geen vier ogen: een machine beoordeelt wat een machine kan
beoordelen. Ze merkt niet dat een ontwerp verkeerd is of dat een belofte in de
interface meer zegt dan de code doet.

En de asymmetrie loopt één kant op: een binnengekomen pull request wordt wél
door een niet-auteur bekeken. Alleen het eigen werk van de beheerder gaat
ongezien door. Dat is in beide richtingen het weten waard.

Closes #554

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

QA.05 is de vinkjes waar de verleiding het grootst is: Dart is geheugenveilig,
dus aanvinken en door. Maar opencv_core trekt dartcv binnen, dat is C++, en het
is precies de laag die niet-vertrouwde beeldbytes decodeert.

De maatregelen bleken beter dan de issue aannam — er staat een poort vóór de
decode die alléén de kop leest, met een pixelgrens die de bestandsgrens níét kan
vervangen, en fail-closed bij een onleesbare kop. Dat stond nergens opgeschreven.

Wat wél nieuw is, is gemeten in plaats van beredeneerd, en het corrigeert mijn
eigen aanname onderweg:

- een afgekapt bestand komt er in geen enkel formaat door, ook niet op 4 KiB —
  ruim voorbij de plek waar de afmetingen staan;
- een verminkte PNG evenmin, want CRC per chunk plus verplichte IEND;
- een verminkte JPEG kómt er wél doorheen, want de SOF draagt de afmetingen
  zonder checksum. Díe bytes gaan de C++-decoder in.

Dat laatste is geen gat maar de eerlijke vorm van de maatregel: de poort
begrenst de allocatie, niet de inhoud. De regressietest legt beide kanten vast,
inclusief de JPEG die er bewust wél doorheen moet — draait ooit iemand dat
stilletijk om, dan verandert welke bytes de native laag bereiken.

Met DARTCV_LIB_PATH gezet draaien de tests écht door de C++-decoder: 19 groen,
en de verminkte JPEG komt onleesbaar terug in plaats van om te vallen.

Wat niet gedekt is staat er ook: geen fuzzingcorpus, en een crash ín dartcv
neemt het proces mee.

Closes #553

docs: publiceer de vrijwillige beveiligingsattestatie (COMPLIANCE.md) ... 2007f0e7cf

De paraplu van de tros. Bijna alles bestond al en stond nergens bij elkaar; dit
verzamelt het tegen de lichte VSA-checklist van de ORC WG, met per regel een
verwijzing naar wat hem draagt.

Drie regels zijn niet aangevinkt en dat is de kern van het document. QA.06 en
QA.07 (één bijdrager, zelf mergen) en de release-regels BR.02-04 (er zijn geen
releases). Een checklist die zijn zwakste regel stil aanvinkt, leert de lezer de
regels te wantrouwen die wél kloppen — dus staat er onderaan ook een kopje "waar
dit het zwakst is", te lezen vóór je besluit hierop te bouwen.

Twee claims onderweg gecorrigeerd omdat ze niet klopten. De termijnen (5/10/90)
staan in tool/check_service_norms.dart en NIET in SECURITY.md; ze staan er nu bij
als "wat wij meten", uitdrukkelijk niet als toezegging aan een melder — een
nalevingsdocument is niet de plek om een belofte stilletjes op te waarderen. En
het adres van de stichting verzin ik niet: dat veld verwijst naar de eigen
registratie.

Er hoort een poort bij, want dit is het document dat het stilst veroudert.
`compliance_attestation_test.dart` toetst dat elke verwijzing bestaat, dat het
meldadres gelijk is aan dat in SECURITY.md, en dat QA.06/QA.07 niet ongemerkt
aangevinkt raken. In drie richtingen geplant en afgegaan.

Closes #549

brenno merged commit b67741c7e1 into main 2026-07-22 15:40:55 +00:00

brenno referenced this pull request from a commit 2026-07-22 15:40:57 +00:00

Merge pull request 'docs: de CRA-attestatietros — rentmeester, EOL, feed, geheugenveiligheid, busfactor en COMPLIANCE.md' (#566) from docs/cra-rentmeester into main

brenno referenced this pull request 2026-07-22 15:41:07 +00:00

[Feature] Publish a light-weight voluntary security attestation (COMPLIANCE.md) #549

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

accepted

Assessed and will be built

  

bug

Something is broken

  

declined

Assessed and will not be built

  

docs

Documentation only

  

duplicate

Already tracked elsewhere

  

enhancement

New feature or improvement request

  

good first issue

Small, self-contained, and a good place to start

  

in-progress

Someone is working on this right now. Do not start it in parallel.

  

needs-info

Waiting for the reporter

  

privacy

Personal data can leak. Handled before anything else.

  

security

A weakness someone could use. Handled before anything else.

  

triage

Awaiting assessment

No labels

accepted

bug

declined

docs

duplicate

enhancement

good first issue

in-progress

needs-info

privacy

security

triage

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

LibreKAT/Ocideck!566

No description provided.