security_insights_test pint een onwaarheid vast: de attestatiedocumenten beschrijven een project zonder releases en zonder CI #1889

New issue

Closed

opened 2026-08-31 13:36:21 +00:00 by brenno · 0 comments

brenno commented

2026-08-31 13:36:21 +00:00

Owner

De twee documenten waarmee het project zich naar buiten verantwoordt —
security-insights.yml (OpenSSF Security Insights, machineleesbaar) en
COMPLIANCE.md (de vrijwillige ORC WG-attestatie) — beschrijven een project dat
niet meer bestaat. En het ergste: een test houdt de onwaarheid op zijn plek.

De poort pint de onwaarheid vast

test/security_insights_test.dart:88:

test('er worden geen releases beweerd die er niet zijn', () {
  expect(release['automated-pipeline'], isFalse);
  expect(release.containsKey('distribution-points'), isFalse);
  expect(release.containsKey('attestations'), isFalse);
});

Toen dit werd geschreven was het waar. Nu zijn er 23 v*-tags, de laatste
v0.4.9 van 23-08-2026, met minisign-ondertekende artefacten, een
Homebrew-cask, een AUR-PKGBUILD, een Windows-installer en een
release.yml-keten die vier platformen bouwt en publiceert. Wie
security-insights.yml naar waarheid bijwerkt, maakt make check rood. De
poort beschermt niet langer een waarheid; hij handhaaft een onjuistheid.

Wat er verder niet meer klopt

security-insights.yml:

accepts-automated-change-request: false, met als toelichting "No bots, no
Dependabot, no CI runner on the forge" — er draait er een sinds
23-07-2026.
release.comment: "There are no releases yet: no tags, no built artefacts, no
distribution points. Users build from source and pin a commit — the commit
hash is the only version identifier that exists."
Alle vier de gereedschappen (Semgrep, gitleaks, TruffleHog, OSV) staan op
integration: { ci: false, release: false }. Semgrep en de twee
geheimenscanners draaien op élke pull request via
.forgejo/workflows/scans.yml.
Slotzin: "Every tool above runs on the maintainer's machine, never on the
forge: there is no CI runner."

COMPLIANCE.md:

AU.03 Scope: "There are no releases and no version tags".
"pubspec.yaml carries 0.1.0+1" — het is 0.4.10+24.
QA.04: "They run locally; there is no CI runner (see QA.06)."
BR.04: "No releases — but the log exists".
Vulnerability management: "It is empty today, because there are no
releases" over releases.rss — daar staan er 23 in.
"Where this is weakest", punt 2: "No releases, so no signed or verifiable
artefacts (BR.02–04). You build from source and pin a commit; there is no
update mechanism" — er is een ondertekende releaseketen én een Homebrew-tap
met een dagelijkse spiegelcontrole.

Beide documenten dragen "Issued 2026-07-22". Ze verklaren het project
consequent zwakker dan het is, wat de veilige richting is, maar ze zijn
onjuist en dat is voor een attestatie het punt. Wie op grond van
COMPLIANCE.md beslist of hij hierop durft te bouwen, krijgt een verkeerd
beeld; en security-insights.yml is bedoeld om machinaal gelezen te worden.

Het mechanisme bestaat al, maar te smal

test/docs_claims_match_code_test.dart doet exact het goede: het toetst
prozaclaims tegen de code, en het heeft al een groep die COMPLIANCE.md
bewaakt (uit #579, toen dat document iets absoluuts beweerde dat niet klopte).
Die groep gaat alleen over de eigen server, de spiegel en de webdemo. De veel
zwaardere claims — releases, tags, CI-runner, versienummer — staan er niet in.

Voorstel

security-insights.yml bijwerken naar de werkelijkheid: automated-pipeline: true, distribution-points en attestations invullen, per gereedschap
ci: true waar dat klopt, de "no CI runner"-toelichtingen weg.
test/security_insights_test.dart omdraaien: niet meer "er zijn geen
releases" vastpinnen, maar toetsen dat de bewering overeenkomt met de
werkelijkheid — bestaan er v*-tags, dan moeten distribution-points en
attestations er zijn; bestaan ze niet, dan niet.
COMPLIANCE.md herzien op de zes plekken hierboven, met een nieuwe
uitgiftedatum.
In docs_claims_match_code_test.dart erbij: het aantal tags, het
versienummer uit pubspec.yaml en het bestaan van een CI-runner tegen wat
deze twee documenten beweren. Anders verloopt dit opnieuw stil.

Gevonden bij een kritische review van het kwaliteitsbewakingssysteem, 31-08-2026.

De twee documenten waarmee het project zich naar buiten verantwoordt — `security-insights.yml` (OpenSSF Security Insights, machineleesbaar) en `COMPLIANCE.md` (de vrijwillige ORC WG-attestatie) — beschrijven een project dat niet meer bestaat. En het ergste: **een test houdt de onwaarheid op zijn plek.** ## De poort pint de onwaarheid vast `test/security_insights_test.dart:88`: ```dart test('er worden geen releases beweerd die er niet zijn', () { expect(release['automated-pipeline'], isFalse); expect(release.containsKey('distribution-points'), isFalse); expect(release.containsKey('attestations'), isFalse); }); ``` Toen dit werd geschreven was het waar. Nu zijn er **23 `v*`-tags**, de laatste `v0.4.9` van 23-08-2026, met minisign-ondertekende artefacten, een Homebrew-cask, een AUR-PKGBUILD, een Windows-installer en een `release.yml`-keten die vier platformen bouwt en publiceert. Wie `security-insights.yml` naar waarheid bijwerkt, **maakt `make check` rood**. De poort beschermt niet langer een waarheid; hij handhaaft een onjuistheid. ## Wat er verder niet meer klopt `security-insights.yml`: - `accepts-automated-change-request: false`, met als toelichting "No bots, no Dependabot, **no CI runner on the forge**" — er draait er een sinds 23-07-2026. - `release.comment`: "There are no releases yet: no tags, no built artefacts, no distribution points. Users build from source and pin a commit — the commit hash is the only version identifier that exists." - Alle vier de gereedschappen (Semgrep, gitleaks, TruffleHog, OSV) staan op `integration: { ci: false, release: false }`. Semgrep en de twee geheimenscanners draaien op **élke pull request** via `.forgejo/workflows/scans.yml`. - Slotzin: "Every tool above runs on the maintainer's machine, never on the forge: there is no CI runner." `COMPLIANCE.md`: - AU.03 Scope: "There are no releases and no version tags". - "`pubspec.yaml` carries `0.1.0+1`" — het is `0.4.10+24`. - QA.04: "They run locally; there is no CI runner (see QA.06)." - BR.04: "No releases — but the log exists". - Vulnerability management: "It is **empty today**, because there are no releases" over `releases.rss` — daar staan er 23 in. - "Where this is weakest", punt 2: "**No releases, so no signed or verifiable artefacts** (BR.02–04). You build from source and pin a commit; there is no update mechanism" — er is een ondertekende releaseketen én een Homebrew-tap met een dagelijkse spiegelcontrole. Beide documenten dragen "Issued 2026-07-22". Ze verklaren het project consequent *zwakker* dan het is, wat de veilige richting is, maar ze zijn onjuist en dat is voor een attestatie het punt. Wie op grond van `COMPLIANCE.md` beslist of hij hierop durft te bouwen, krijgt een verkeerd beeld; en `security-insights.yml` is bedoeld om machinaal gelezen te worden. ## Het mechanisme bestaat al, maar te smal `test/docs_claims_match_code_test.dart` doet exact het goede: het toetst prozaclaims tegen de code, en het heeft al een groep die `COMPLIANCE.md` bewaakt (uit #579, toen dat document iets absoluuts beweerde dat niet klopte). Die groep gaat alleen over de eigen server, de spiegel en de webdemo. De veel zwaardere claims — releases, tags, CI-runner, versienummer — staan er niet in. ## Voorstel 1. `security-insights.yml` bijwerken naar de werkelijkheid: `automated-pipeline: true`, `distribution-points` en `attestations` invullen, per gereedschap `ci: true` waar dat klopt, de "no CI runner"-toelichtingen weg. 2. `test/security_insights_test.dart` omdraaien: niet meer "er zijn geen releases" vastpinnen, maar toetsen dat de bewering **overeenkomt met de werkelijkheid** — bestaan er `v*`-tags, dan moeten `distribution-points` en `attestations` er zijn; bestaan ze niet, dan niet. 3. `COMPLIANCE.md` herzien op de zes plekken hierboven, met een nieuwe uitgiftedatum. 4. In `docs_claims_match_code_test.dart` erbij: het aantal tags, het versienummer uit `pubspec.yaml` en het bestaan van een CI-runner tegen wat deze twee documenten beweren. Anders verloopt dit opnieuw stil. _Gevonden bij een kritische review van het kwaliteitsbewakingssysteem, 31-08-2026._

brenno added the

bug

docs

labels

2026-08-31 13:36:21 +00:00

brenno added the

in-progress

label

2026-08-31 15:47:20 +00:00

brenno referenced this issue from a commit

2026-08-31 15:57:06 +00:00

fix(security): .DS_Store uit webbundel, attestatie op waarheid, branch-protection (#1888, #1889, #1891)