LibreKAT/Ocideck

Watch

Fork 0

fix(scans): de poort wordt niet meer rood om iets wat geen vondst is #805

Merged

brenno merged 3 commits from fix/scans-concurrency into main

2026-07-24 16:55:09 +00:00

brenno commented

2026-07-24 16:15:26 +00:00

Owner

Nazorg bij #778 / PR #799. De aanleiding is gemeten, niet vermoed.

Twee keer op één middag stond de scanpoort rood zonder dat er iets gevonden was (op fc2d0a94 en op deze eigen PR). De joblogs op de forge wijzen beide keren dezelfde oorzaak aan, een halve seconde na de checkout:

curl: (22) The requested URL returned error: 504
[runner]: exitcode "22": failure

Op precies die commits zijn make check-secrets en make sast lokaal groen, en op de huidige main ook. Het was dus de download van een gepinde scanner die omviel, niet de repo.

Voor déze poort is dat de duurste faalvorm die er is: een rood beveiligingsvinkje dat geen vondst is, leert je het volgende rode vinkje ook weg te klikken. Dan staat de poort er nog wel, maar werkt hij niet meer.

Twee oorzaken, twee reparaties

De downloads herhalen op 5xx met een oplopende wachttijd. Deze poort haalt drie scanners van het net bij élke PR en élke push — even zo vaak een kans op een storing buiten deze repo.
Een opzijgezette run breekt netjes af in plaats van zich als failure te melden (concurrency per ref). Afbreken kost hier niets, en dat is geen aanname over snelheid maar een eigenschap van de meting: beide historie-scans lezen de héle historie, dus de latere run dekt onverkort wat de afgebroken run zou hebben gezien. Bij een poort die alléén de wijziging bekijkt zou dit juist fout zijn, en dat staat als waarschuwing in de workflow.

Dat Forgejo (16.0.1) de concurrency-sleutel slikt is gecontroleerd en niet aangenomen — de taak verscheen op deze PR, en in het runnerlog staat een nette RESULT_CANCELLED voor een opzijgezette taak. Een niet-herkende sleutel had de scan stil kunnen uitschakelen.

Een correctie op mezelf

In #801 schreef ik dat de scanners niet gecachet worden omdat drie minuten de staleness niet waard is. Dat was het zwakke argument. Het echte staat er nu: een cache-restore zou een sha256-geverifieerde download van een beveiligingsscanner vervangen door een artefact uit een eerdere run — en anders dan bij de toolchain in linux-gate.yml, waar check-toolchain de herstelde boom opnieuw toetst, is er hier geen tweede controle. Cachen zou precies de eigenschap opeten waar #778 om begonnen is.

make check groen.

Nazorg bij #778 / PR #799. **De aanleiding is gemeten, niet vermoed.** Twee keer op één middag stond de scanpoort rood zonder dat er iets gevonden was (op `fc2d0a94` en op deze eigen PR). De joblogs op de forge wijzen beide keren dezelfde oorzaak aan, een halve seconde na de checkout: ``` curl: (22) The requested URL returned error: 504 [runner]: exitcode "22": failure ``` Op precies die commits zijn `make check-secrets` en `make sast` lokaal groen, en op de huidige main ook. Het was dus de download van een gepinde scanner die omviel, niet de repo. Voor déze poort is dat de duurste faalvorm die er is: **een rood beveiligingsvinkje dat geen vondst is, leert je het volgende rode vinkje ook weg te klikken.** Dan staat de poort er nog wel, maar werkt hij niet meer. ### Twee oorzaken, twee reparaties 1. **De downloads herhalen op 5xx** met een oplopende wachttijd. Deze poort haalt drie scanners van het net bij élke PR en élke push — even zo vaak een kans op een storing buiten deze repo. 2. **Een opzijgezette run breekt netjes af** in plaats van zich als `failure` te melden (`concurrency` per ref). Afbreken kost hier niets, en dat is geen aanname over snelheid maar een eigenschap van de meting: beide historie-scans lezen de héle historie, dus de latere run dekt onverkort wat de afgebroken run zou hebben gezien. Bij een poort die alléén de wijziging bekijkt zou dit juist fout zijn, en dat staat als waarschuwing in de workflow. Dat Forgejo (16.0.1) de `concurrency`-sleutel slikt is gecontroleerd en niet aangenomen — de taak verscheen op deze PR, en in het runnerlog staat een nette `RESULT_CANCELLED` voor een opzijgezette taak. Een niet-herkende sleutel had de scan stil kunnen uitschakelen. ### Een correctie op mezelf In #801 schreef ik dat de scanners niet gecachet worden omdat drie minuten de staleness niet waard is. Dat was het zwakke argument. Het echte staat er nu: een cache-restore zou een sha256-geverifieerde download *van een beveiligingsscanner* vervangen door een artefact uit een eerdere run — en anders dan bij de toolchain in `linux-gate.yml`, waar `check-toolchain` de herstelde boom opnieuw toetst, is er hier geen tweede controle. Cachen zou precies de eigenschap opeten waar #778 om begonnen is. `make check` groen.

brenno added 1 commit

2026-07-24 16:15:26 +00:00

fix(scans): een opzijgezette run mag afbreken, niet rood worden (#778 )

scans / scans (pull_request) Failing after 1m34s

Details

43568f4067

Twee merges naar main binnen een paar minuten leverden een rode scan op
die geen vondst was: de lopende run werd door de volgende opzij gezet en
meldde zich als `failure` (run 2113 op fc2d0a94). Lokaal waren
check-secrets en sast op precies dat commit groen, en op de huidige main
ook.

Dat is voor déze poort de duurste faalvorm die er is. Een rood
beveiligingsvinkje dat niets betekent, leert je het volgende rode vinkje
ook weg te klikken — en dan is de poort er nog wel, maar werkt hij niet
meer.

Afbreken kost hier niets, en dat is geen aanname over snelheid maar een
eigenschap van wat er gemeten wordt: beide historie-scans lezen de héle
historie, dus de latere run dekt onverkort wat de afgebroken run zou
hebben gezien. Bij een poort die alleen de wijziging bekijkt zou dit fout
zijn, en dat staat er daarom bij.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

brenno added 1 commit

2026-07-24 16:35:23 +00:00

fix(scans): de poort wordt niet meer rood om iets wat geen vondst is (#778 )

scans / scans (pull_request) Has been cancelled

Details

6ac5b8b320

Twee keer op één middag stond de scanpoort rood zonder dat er iets
gevonden was. De logs op de forge wijzen beide keren dezelfde oorzaak
aan, een halve seconde na de checkout:

    curl: (22) The requested URL returned error: 504
    [runner]: exitcode '22': failure

Op precies die commits waren `make check-secrets` en `make sast` lokaal
groen, en op de huidige main ook. Het was dus de download van een gepinde
scanner die omviel, niet de repo.

Dat is voor déze poort de duurste faalvorm die er is: een rood
beveiligingsvinkje dat geen vondst is, leert je het volgende rode vinkje
ook weg te klikken. Dan staat de poort er nog wel, maar werkt hij niet
meer.

Twee oorzaken, twee reparaties:

  * de downloads herhalen op 5xx met een oplopende wachttijd. Deze poort
    haalt drie scanners van het net bij élke PR en élke push; dat is even
    zo vaak een kans op een storing buiten deze repo.
  * een run die door een volgende opzij wordt gezet, breekt netjes af in
    plaats van zich als failure te melden (concurrency per ref).
    Afbreken kost hier niets, en dat is geen aanname over snelheid maar
    een eigenschap van de meting: beide historie-scans lezen de héle
    historie, dus de latere run dekt wat de afgebroken run zou hebben
    gezien. Bij een poort die alleen de wijziging bekijkt zou dit fout
    zijn.

En een correctie op mezelf in CHECKS.md. Daar stond dat de scanners niet
gecachet worden omdat drie minuten de staleness niet waard is. Dat was
het zwakke argument. Het echte is dat een cache-restore een
sha256-geverifieerde download *van een beveiligingsscanner* zou
vervangen door een artefact uit een eerdere run — en anders dan bij de
toolchain in linux-gate.yml is er geen check die het herstelde resultaat
opnieuw toetst. Cachen zou hier precies de eigenschap opeten waar #778 om
begonnen is.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

brenno changed title from ~~fix(scans): een opzijgezette run mag afbreken, niet rood worden~~ to fix(scans): de poort wordt niet meer rood om iets wat geen vondst is

2026-07-24 16:35:42 +00:00

brenno added 1 commit

2026-07-24 16:37:02 +00:00

fix(scans): -o hoort ná de retry-vlaggen, niet ervoor (#778 )

scans / scans (pull_request) Successful in 3m17s

Details

66a2b65ff5

De vorige commit schreef `curl -fsSLo --retry 5 …`. Dat is stuk: `-o`
neemt het volgende argument als bestandsnaam, dus curl schreef naar een
bestand `--retry`, las `5` als URL (en probeerde 0.0.0.5 te bereiken), en
dumpte de inhoud naar stdout. Het archief kwam daarmee nooit op
`/tmp/$ARCHIVE` terecht en de sha256-controle erna zou op élke run
omvallen — een poort die permanent rood staat om een reden die geen
vondst is, precies wat deze tak juist wilde wegnemen.

Gemeten in plaats van gelezen, in beide vormen:

  * `-fsSLo --retry 5 …` → geen bestand, `curl: (7) Failed to connect to
    0.0.0.5`, inhoud op stdout;
  * `-fsSL --retry 5 … -o pad` → bestand aangemaakt, en de hele
    gitleaks-stap (download + manifest + `sha256sum -c`) loopt door tot
    "OK".

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

brenno force-pushed fix/scans-concurrency from 66a2b65ff5

scans / scans (pull_request) Successful in 3m17s

Details

to dde666525c

scans / scans (pull_request) Successful in 3m13s

Details

2026-07-24 16:48:33 +00:00

Compare

brenno merged commit d812ede3da into main

2026-07-24 16:55:09 +00:00

brenno referenced this pull request from a commit

2026-07-24 16:55:11 +00:00