ci(scanners): gepinde, sha256-geverifieerde scanners in de GitHub-definitie #804

Merged

brenno merged 5 commits from ci/scanners-gepind-800 into main

2026-07-24 15:55:59 +00:00

brenno commented

2026-07-24 15:52:33 +00:00

Owner

Closes #800

De stap "Gereedschap voor de scanners" in .github/workflows/ci.yml haalde
gitleaks en trufflehog binnen door een installatiescript vanaf de tip van een
branch door sh te pijpen, en semgrep zonder versie:

curl -sSfL https://raw.githubusercontent.com/gitleaks/gitleaks/master/scripts/install.sh | sh -s -- -b /usr/local/bin
curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh | sh -s -- -b /usr/local/bin
python3 -m pip install --quiet semgrep

Twee dingen tegelijk mis: willekeurige code van een bewegende aanwijzer,
ongeverifieerd uitgevoerd, én scanners die zichzelf bijwerken — waardoor "groen"
stilletjes iets anders gaat betekenen dan de week ervoor. #778 benoemde precies
dit als anti-patroon, en zei er in dezelfde alinea bij dat wie de binaries zelf
trekt ze moet verifiëren zoals de Flutter-stap dat doet.

Wat erin zit

1. Gepinde, sha256-geverifieerde installatie — het patroon uit
.forgejo/workflows/scans.yml (#799): de versie in een env-blok, de tarball
binnengehaald en gecontroleerd tegen het gepubliceerde release-manifest, semgrep
gepind in een venv (systeem-pip is op Ubuntu 24.04 afgeschermd, PEP 668). Drie
stappen in plaats van één, zodat de log zegt wélke scanner niet binnenkwam.

Eén bewuste afwijking van scans.yml: de pin staat in het env-blok van zijn
eigen stap en niet in één blok bovenaan de taak. Die taak scant hier niet
alléén, en tachtig regels tussen pin en download is de helft die je bij een bump
vergeet.

2. fetch-depth: 0 op de checkout — losse commit, gevonden bij (1). De taak
checkte uit met de standaard van actions/checkout, één commit diep, en draaide
daarna make check-secrets; twee van de vier passes daarvan lezen de historie
(gitleaks git ., trufflehog git file://.). Op een ondiepe kloon lezen die
bijna niets en eindigen groen — en het geval waarvoor ze bestaan is nu juist het
geheim dat drie commits terug is toegevoegd en daarna "verwijderd".
scans.yml had dit al; alleen deze definitie liep achter. Staat los van de pins
en kan er als losse commit uit.

3. Een vervallen zin uit het commentaar — "geen marketplace-actions, want
die zouden gepind moeten worden": hieronder wordt nu sowieso gepind, dus dat
argument onderscheidt niets meer. De tweede helft (de stapnaam zou liegen) staat
nog.

4. Documentatie — CHECKS.md beschreef de Gate (Linux)-taak zonder
check-audience-boundary, check-secrets en sast, terwijl die stappen er al
in stonden. Aangevuld, plus een punt over wat er nu anders is. CHANGELOG.md
kreeg de ingang.

5. Een correctie op #799, dat tijdens dit werk landde. Zie hieronder.

Dit bestand draait nergens

Forgejo leest .forgejo/workflows/ en dat schaduwt .github/workflows/; dit is
een referentiedefinitie voor een GitHub-spiegel. Er is dus geen CI-run die deze
wijziging bewijst — en om dezelfde reden was er ook geen buildmachine die de
ongepinde code uitvoerde. Het moest toch: dit is het bestand dat een bijdrager
als eerste vindt (#592), en op de dag dat de spiegel er komt draait het wél.

Hoe het dan wél getoetst is

YAML-parse met yq 4.53.2, op beide workflows: ze ontleden, en de drie
env-blokken komen er met de juiste waarden uit.
shellcheck -s bash over de drie run-blokken, uit de YAML geëxtraheerd:
schoon.
De pins nagelopen tegen de echte manifesten.
gitleaks_8.30.1_linux_x64.tar.gz en trufflehog_3.95.9_linux_amd64.tar.gz
staan er allebei in en leveren een sha256 op — de verificatie is op deze
versies dus geen no-op.
De stappen naast scans.yml gelegd; de afwijkingen staan hierboven.
Alle interne ankers in CHECKS.md nagelopen: geen kapotte.
make check groen.

De correctie op #799

De aanleiding voor test -n "$SHA" zoals #799 die opschreef, klopt niet — en hij
staat op drie plekken: het commentaar in scans.yml, de beschrijving in
CHECKS.md en de CHANGELOG-ingang.

Nagemeten met GNU coreutils 9.5 (ubuntu:24.04 draait 9.4, dezelfde codebasis):
bij een lege treffer loopt sha256sum -c - níet stil met exit 0 door. Hij meldt
"no properly formatted checksum lines found" en eindigt op 1 — zowel via een
grep zonder treffer als met een lege $SHA uit awk die als
echo " /pad" | sha256sum -c - binnenkomt.

De regel blijft staan, om een andere reden: zonder hem struikelt de stap over de
invoer van sha256sum, en wie dat leest gaat de verificatie debuggen in plaats
van te zien dat er een release-asset hernoemd is. De CHANGELOG-ingang van #799
krijgt een gedateerde correctie in plaats van een herschrijving — het is een
dagboek, en wat er stond hoort bij hoe het liep.

Bewaker

Geraakt: "iets dat een nieuwe partij vertrouwt". Uitkomst: geen nieuwe partij —
dezelfde uitgevers als voorheen, maar een vast punt in plaats van een bewegend,
mét controle. Eerlijk erbij: het manifest komt van diezelfde uitgever, dus dit is
geen bewijs over de uitgever, en de transitieve afhankelijkheden van semgrep
zijn niet gehasht. Allebei staat het in het commentaar in plaats van stil
gelaten. Bestandsformaat, opslag en app-afhankelijkheden: niet geraakt.

Botsing, hardop: pinnen ruilt "altijd het nieuwste" in voor "reproduceerbaar en
bewust". #778 heeft die knoop doorgehakt en dat is hier gevolgd — maar de
tegenhanger ontbreekt: niets bewaakt dat deze drie getallen verouderen, en een
geheimenscanner die stilstaat mist de sleutelvormen die daarna zijn ontstaan.
Apart ingediend als #802, want het raakt scans.yml net zo hard en het is
een wijziging in tool/, niet in deze workflow.

Closes #800 De stap "Gereedschap voor de scanners" in `.github/workflows/ci.yml` haalde gitleaks en trufflehog binnen door een installatiescript vanaf de **tip van een branch** door `sh` te pijpen, en semgrep zonder versie: ``` curl -sSfL https://raw.githubusercontent.com/gitleaks/gitleaks/master/scripts/install.sh | sh -s -- -b /usr/local/bin curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh | sh -s -- -b /usr/local/bin python3 -m pip install --quiet semgrep ``` Twee dingen tegelijk mis: willekeurige code van een bewegende aanwijzer, ongeverifieerd uitgevoerd, én scanners die zichzelf bijwerken — waardoor "groen" stilletjes iets anders gaat betekenen dan de week ervoor. #778 benoemde precies dit als anti-patroon, en zei er in dezelfde alinea bij dat wie de binaries zelf trekt ze moet verifiëren zoals de Flutter-stap dat doet. ## Wat erin zit **1. Gepinde, sha256-geverifieerde installatie** — het patroon uit `.forgejo/workflows/scans.yml` (#799): de versie in een `env`-blok, de tarball binnengehaald en gecontroleerd tegen het gepubliceerde release-manifest, semgrep gepind in een venv (systeem-pip is op Ubuntu 24.04 afgeschermd, PEP 668). Drie stappen in plaats van één, zodat de log zegt wélke scanner niet binnenkwam. Eén bewuste afwijking van `scans.yml`: de pin staat in het `env`-blok van zijn eigen stap en niet in één blok bovenaan de taak. Die taak scant hier niet alléén, en tachtig regels tussen pin en download is de helft die je bij een bump vergeet. **2. `fetch-depth: 0` op de checkout** — losse commit, gevonden bij (1). De taak checkte uit met de standaard van `actions/checkout`, één commit diep, en draaide daarna `make check-secrets`; twee van de vier passes daarvan lezen de *historie* (`gitleaks git .`, `trufflehog git file://.`). Op een ondiepe kloon lezen die bijna niets en eindigen groen — en het geval waarvoor ze bestaan is nu juist het geheim dat drie commits terug is toegevoegd en daarna "verwijderd". `scans.yml` had dit al; alleen deze definitie liep achter. Staat los van de pins en kan er als losse commit uit. **3. Een vervallen zin uit het commentaar** — "geen marketplace-actions, want die zouden gepind moeten worden": hieronder wordt nu sowieso gepind, dus dat argument onderscheidt niets meer. De tweede helft (de stapnaam zou liegen) staat nog. **4. Documentatie** — `CHECKS.md` beschreef de Gate (Linux)-taak zonder `check-audience-boundary`, `check-secrets` en `sast`, terwijl die stappen er al in stonden. Aangevuld, plus een punt over wat er nu anders is. `CHANGELOG.md` kreeg de ingang. **5. Een correctie op #799, dat tijdens dit werk landde.** Zie hieronder. ## Dit bestand draait nergens Forgejo leest `.forgejo/workflows/` en dat schaduwt `.github/workflows/`; dit is een referentiedefinitie voor een GitHub-spiegel. **Er is dus geen CI-run die deze wijziging bewijst** — en om dezelfde reden was er ook geen buildmachine die de ongepinde code uitvoerde. Het moest toch: dit is het bestand dat een bijdrager als eerste vindt (#592), en op de dag dat de spiegel er komt draait het wél. ## Hoe het dan wél getoetst is - **YAML-parse** met `yq` 4.53.2, op beide workflows: ze ontleden, en de drie `env`-blokken komen er met de juiste waarden uit. - **`shellcheck -s bash`** over de drie `run`-blokken, uit de YAML geëxtraheerd: schoon. - **De pins nagelopen tegen de echte manifesten.** `gitleaks_8.30.1_linux_x64.tar.gz` en `trufflehog_3.95.9_linux_amd64.tar.gz` staan er allebei in en leveren een sha256 op — de verificatie is op deze versies dus geen no-op. - **De stappen naast `scans.yml` gelegd**; de afwijkingen staan hierboven. - **Alle interne ankers in `CHECKS.md` nagelopen**: geen kapotte. - `make check` groen. ## De correctie op #799 De aanleiding voor `test -n "$SHA"` zoals #799 die opschreef, klopt niet — en hij staat op drie plekken: het commentaar in `scans.yml`, de beschrijving in `CHECKS.md` en de CHANGELOG-ingang. Nagemeten met GNU coreutils 9.5 (`ubuntu:24.04` draait 9.4, dezelfde codebasis): bij een lege treffer loopt `sha256sum -c -` níet stil met exit 0 door. Hij meldt "no properly formatted checksum lines found" en eindigt op 1 — zowel via een `grep` zonder treffer als met een lege `$SHA` uit `awk` die als `echo " /pad" | sha256sum -c -` binnenkomt. De regel blijft staan, om een andere reden: zonder hem struikelt de stap over de *invoer van sha256sum*, en wie dat leest gaat de verificatie debuggen in plaats van te zien dat er een release-asset hernoemd is. De CHANGELOG-ingang van #799 krijgt een gedateerde correctie in plaats van een herschrijving — het is een dagboek, en wat er stond hoort bij hoe het liep. ## Bewaker Geraakt: "iets dat een nieuwe partij vertrouwt". Uitkomst: geen nieuwe partij — dezelfde uitgevers als voorheen, maar een vast punt in plaats van een bewegend, mét controle. Eerlijk erbij: het manifest komt van diezelfde uitgever, dus dit is geen bewijs *over* de uitgever, en de transitieve afhankelijkheden van semgrep zijn niet gehasht. Allebei staat het in het commentaar in plaats van stil gelaten. Bestandsformaat, opslag en app-afhankelijkheden: niet geraakt. Botsing, hardop: pinnen ruilt "altijd het nieuwste" in voor "reproduceerbaar en bewust". #778 heeft die knoop doorgehakt en dat is hier gevolgd — maar de tegenhanger ontbreekt: niets bewaakt dat deze drie getallen verouderen, en een geheimenscanner die stilstaat mist de sleutelvormen die daarna zijn ontstaan. Apart ingediend als **#802**, want het raakt `scans.yml` net zo hard en het is een wijziging in `tool/`, niet in deze workflow.

brenno added 5 commits

2026-07-24 15:52:33 +00:00

ci(scanners): gepinde en sha256-geverifieerde installatie in plaats van curl | sh f56189872d

De stap "Gereedschap voor de scanners" haalde gitleaks en trufflehog binnen als
installatiescript vanaf de tip van een branch (master/main), en semgrep zonder
versie. Twee dingen tegelijk mis: willekeurige code van een bewegende aanwijzer,
ongeverifieerd uitgevoerd, én scanners die zichzelf bijwerken — waardoor "groen"
stilletjes iets anders gaat betekenen dan de week ervoor. #778 benoemde precies
dit als anti-patroon, en zei er in dezelfde alinea bij dat wie de binaries zelf
trekt ze moet verifiëren zoals de Flutter-stap dat doet.

Neemt het patroon over uit .forgejo/workflows/scans.yml (#799): de versie in een
env-blok, de tarball binnengehaald en sha256 gecontroleerd tegen het
gepubliceerde release-manifest, semgrep gepind in een venv (systeem-pip is op
Ubuntu 24.04 afgeschermd, PEP 668). Drie stappen in plaats van één, zodat de log
zegt wélke scanner niet binnenkwam. Eén afwijking, bewust: de pin staat per stap
en niet in één blok bovenaan de taak — deze taak scant niet alléén, en tachtig
regels tussen pin en download is de helft die je bij een bump vergeet.

DIT BESTAND DRAAIT NERGENS. Forgejo leest .forgejo/workflows/ en dat schaduwt
.github/workflows/; dit is een referentiedefinitie voor een GitHub-spiegel. Er is
dus geen CI-run die deze wijziging bewijst — en er was om dezelfde reden ook geen
buildmachine die de ongepinde code uitvoerde. Getoetst met een YAML-parse (yq
4.53.2), shellcheck over de drie run-blokken, en door de stappen naast scans.yml
te leggen. De pins zijn nagelopen tegen de echte manifesten: beide asset-namen
leveren een sha256 op, dus de verificatie is geen no-op op deze versies.

Het commentaar bij `test -n "$SHA"` wijkt af van dat in scans.yml, omdat het daar
gedane verhaal hier is nagemeten en niet klopt: GNU coreutils 9.5 laat
`sha256sum -c -` bij een lege treffer níet met exit 0 doorlopen, hij eindigt op 1
met "no properly formatted checksum lines found". De regel blijft staan — zonder
hem struikelt de stap over de invoer van sha256sum en gaat de lezer de
verificatie debuggen in plaats van het hernoemde release-asset te zien.

Closes #800

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

ci(scanners): fetch-depth 0, anders scant de geheimenscan bijna niets 8a0a23624d

Gevonden bij de vorige commit, in dezelfde stappen: het gate-werk checkt uit met
de standaardinstelling van actions/checkout — één commit diep — en draait daarna
`make check-secrets`. Dat doel doet vier passes, en twee daarvan gaan over de
histórie (`gitleaks git .`, `trufflehog git file://.`). Op een ondiepe kloon
kijken die naar bijna niets en eindigen groen.

Dat is erger dan geen scan: het geval waarvoor de historie-passes bestaan is het
geheim dat drie commits terug is toegevoegd en daarna "verwijderd" — precies wat
een ondiepe kloon niet meer ziet. Een groen vinkje dat niets heeft gelezen, leest
als een schone repo.

`.forgejo/workflows/scans.yml` heeft dit al (#799, mét de meting erbij dat een
volledige kloon op 1 en 183 eindigt waar de ondiepe twee keer op 0 eindigt);
alleen de GitHub-definitie liep achter. Zit los van de pins en staat daarom in
een eigen commit — valt hij eruit, dan blijft de rest heel.

Ook hier geldt: dit bestand draait nergens (Forgejo leest .forgejo/workflows/),
dus er is geen run die het bewijst. Getoetst met een YAML-parse.

Refs #800

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

docs(poort): de gepinde scanners en de diepe checkout in de GitHub-definitie dc564b7286

CHECKS.md beschreef de Gate (Linux)-taak zonder `check-audience-boundary`,
`check-secrets` en `sast` — die stappen staan er al in het bestand, maar niet in
de beschrijving. Aangevuld, plus een punt over wat er nu anders is: gepinde
releases met sha256 tegen het manifest (dezelfde vorm als de Flutter-tarball in
linux-gate.yml) en `fetch-depth: 0`, met de reden waarom die twee samenhangen.

CHANGELOG kreeg de ingang, met de meting die onderweg de aanleiding voor
`test -n "$SHA"` bijstelde en met de zin die er niet uit weg mag: dit bestand
draait nergens, dus geen CI-run bewijst het.

Refs #800

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

ci(scanners): de vervallen helft van de marketplace-rechtvaardiging f900efb12f

"Bewust géén marketplace-actions: die zouden gepind moeten worden en de stapnaam
zou liegen." De tweede helft staat nog: `make check-secrets` draait gitleaks én
trufflehog, dus geen enkele losse action kan die stap eerlijk benoemen. De eerste
helft is sinds de vorige commits onzin — er wordt hieronder sowieso gepind, dus
"moeten pinnen" onderscheidt niets meer.

Laten staan zou het commentaar een argument laten voeren dat de code eronder
tegenspreekt. Zelfde soort opruiming als 3300734e bij nosemgrepBaseline.

Refs #800

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

docs(scans): de aanleiding voor test -n "$SHA" klopt niet — nagemeten

scans / scans (pull_request) Successful in 3m11s

Details

9a2813bc25

#799 landde met de zin dat `grep … | sha256sum -c -` stil met exit 0 slaagt bij
een lege treffer, op drie plekken: het commentaar in scans.yml, de beschrijving
in CHECKS.md en de CHANGELOG-ingang. Nagemeten op GNU coreutils 9.5 (ubuntu:24.04
draait 9.4, dezelfde codebasis) klopt dat niet — bij een lege treffer meldt
sha256sum "no properly formatted checksum lines found" en eindigt op 1. Getoetst
in beide vormen: een `grep` zonder treffer, en een lege `$SHA` uit `awk` die als
`echo "  /pad" | sha256sum -c -` binnenkomt.

Het vangnet zit er dus al, en de regel blijft staan om een andere reden: zonder
hem struikelt de stap over de invoer van sha256sum, en dan debugt de lezer de
verificatie in plaats van het hernoemde release-asset te zien. Dat is precies
zo'n zin die na een jaar niemand meer natrekt, dus hij wordt hier gecorrigeerd in
plaats van overgeschreven.

De CHANGELOG-ingang van #799 krijgt een gedateerde correctie in plaats van een
herschrijving — het is een dagboek, en wat er stond is onderdeel van hoe het
liep.

Verder in deze commit: de CHANGELOG-ingang van #800 staat weer bovenaan (de
rebase zette hem onder die van #799, terwijl het log omgekeerd-chronologisch is),
en de verwijzing naar scans.yml in CHECKS.md is een echte link geworden nu die
sectie op main bestaat. Alle interne ankers in CHECKS.md nagelopen: geen kapotte.

Refs #800, #799

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