#800 - De scanners in .github/workflows/ci.yml zijn ongepind en komen via curl | sh van een branch-tip - LibreKAT/Ocideck - Pawprint: You digital pawprint in a cat-savy internet

brenno commented

2026-07-24 15:35:07 +00:00

Owner

Wat er speelt

De stap "Gereedschap voor de scanners" in .github/workflows/ci.yml haalt twee
van de drie scanners binnen als installatiescript vanaf de tip van een
branch, en de derde 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

Er zijn twee dingen mis, en ze staan los van elkaar.

1. Ongepind. Dit is precies wat #778 als anti-patroon benoemde: "pin de
scanners op een versie — een scanner die zichzelf bijwerkt verandert stilletjes
wat de poort betekent." Groen vandaag betekent dan iets anders dan groen
gisteren, zonder dat iemand iets wijzigde. De andere kant is even vervelend: een
nieuwe scannerversie kan rood staan op code die niemand heeft aangeraakt, en dan
is de faalreden een upgrade die nergens in de historie staat.

2. curl | sh vanaf een bewegend punt. master en main zijn geen
versies maar aanwijzers. Wat er binnenkomt is willekeurige code die als eerste
stap wordt uitgevoerd — geen tag, geen checksum, geen enkele verificatie. Wie dat
script kan wijzigen, voert opdrachten uit op de buildmachine. #778 zei ook dit al
met zoveel woorden: "Wie de drie binaries in het ubuntu:24.04-image trekt,
moet ze verifiëren zoals de Flutter-stap dat doet (checksum tegen het
release-manifest), anders verplaats je het vertrouwensprobleem naar de
download."

Wat er al goed staat, en wat er over te nemen valt

Voor de wél draaiende workflow is dit opgelost in PR #799
(.forgejo/workflows/scans.yml): de drie versies in één env-blok, de tarball
binnengehaald en sha256 gecontroleerd tegen het gepubliceerde release-manifest,
en semgrep gepind geïnstalleerd in een venv.

Inclusief één regel die er onbenullig uitziet en dat niet is:

test -n "$SHA"

grep … | sha256sum -c - slaagt stil met exit 0 zodra de grep niets vindt.
Eén hernoemd release-asset en de verificatie is er niet meer, zonder één rood
vinkje. Die regel hoort mee over te komen, niet alleen het idee erachter.

Wat dit expliciet níet is

Geen lek en geen storing. .github/workflows/ci.yml draait nergens: Forgejo
leest .forgejo/workflows/ en die map schaduwt deze. Het bestand is een
referentiedefinitie voor een GitHub-spiegel. Er is dus op dit moment geen
buildmachine die ongepinde code van een branch-tip uitvoert.

Waarom het dan toch moet:

het is het bestand dat een bijdrager als eerste vindt (#592), en het doet nu
het tegenovergestelde voor van wat het project elders van zichzelf eist;
op de dag dat de spiegel er komt, draait het wél — en dan is dit geen
voorbeeld meer maar een uitvoerende stap.

Wat het niet raakt

Het bestandsformaat, de opslag, de afhankelijkheden van de app: niets. Dit is
alleen een CI-definitie.

Hoe je het toetst

Er is geen CI-run die de wijziging bewijst — de workflow draait niet, en dat is
by design. Toets daarom met een YAML-parse (yq) en door de stappen naast
scans.yml te leggen. Dat moet in de commit- en PR-tekst staan, anders leest de
volgende lezer een groene poort in die er niet is.

Reikwijdte

Eén stap in één bestand, plus de beschrijving van die workflow in
docs/CHECKS.md.

## Wat er speelt De stap "Gereedschap voor de scanners" in `.github/workflows/ci.yml` haalt twee van de drie scanners binnen als installatiescript vanaf de **tip van een branch**, en de derde 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 ``` Er zijn twee dingen mis, en ze staan los van elkaar. **1. Ongepind.** Dit is precies wat #778 als anti-patroon benoemde: *"pin de scanners op een versie — een scanner die zichzelf bijwerkt verandert stilletjes wat de poort betekent."* Groen vandaag betekent dan iets anders dan groen gisteren, zonder dat iemand iets wijzigde. De andere kant is even vervelend: een nieuwe scannerversie kan rood staan op code die niemand heeft aangeraakt, en dan is de faalreden een upgrade die nergens in de historie staat. **2. `curl | sh` vanaf een bewegend punt.** `master` en `main` zijn geen versies maar aanwijzers. Wat er binnenkomt is willekeurige code die als eerste stap wordt uitgevoerd — geen tag, geen checksum, geen enkele verificatie. Wie dat script kan wijzigen, voert opdrachten uit op de buildmachine. #778 zei ook dit al met zoveel woorden: *"Wie de drie binaries in het `ubuntu:24.04`-image trekt, moet ze verifiëren zoals de Flutter-stap dat doet (checksum tegen het release-manifest), anders verplaats je het vertrouwensprobleem naar de download."* ## Wat er al goed staat, en wat er over te nemen valt Voor de wél draaiende workflow is dit opgelost in PR #799 (`.forgejo/workflows/scans.yml`): de drie versies in één `env`-blok, de tarball binnengehaald en sha256 gecontroleerd tegen het gepubliceerde release-manifest, en semgrep gepind geïnstalleerd in een venv. Inclusief één regel die er onbenullig uitziet en dat niet is: ``` test -n "$SHA" ``` `grep … | sha256sum -c -` slaagt **stil** met exit 0 zodra de grep niets vindt. Eén hernoemd release-asset en de verificatie is er niet meer, zonder één rood vinkje. Die regel hoort mee over te komen, niet alleen het idee erachter. ## Wat dit expliciet níet is **Geen lek en geen storing.** `.github/workflows/ci.yml` draait nergens: Forgejo leest `.forgejo/workflows/` en die map schaduwt deze. Het bestand is een referentiedefinitie voor een GitHub-spiegel. Er is dus op dit moment geen buildmachine die ongepinde code van een branch-tip uitvoert. Waarom het dan toch moet: - het is het bestand dat een bijdrager als eerste vindt (#592), en het doet nu het tegenovergestelde voor van wat het project elders van zichzelf eist; - op de dag dat de spiegel er komt, draait het wél — en dan is dit geen voorbeeld meer maar een uitvoerende stap. ## Wat het niet raakt Het bestandsformaat, de opslag, de afhankelijkheden van de app: niets. Dit is alleen een CI-definitie. ## Hoe je het toetst Er is geen CI-run die de wijziging bewijst — de workflow draait niet, en dat is by design. Toets daarom met een YAML-parse (`yq`) en door de stappen naast `scans.yml` te leggen. Dat moet in de commit- en PR-tekst staan, anders leest de volgende lezer een groene poort in die er niet is. ## Reikwijdte Eén stap in één bestand, plus de beschrijving van die workflow in `docs/CHECKS.md`.

brenno added the

security

accepted

in-progress

labels

2026-07-24 15:35:07 +00:00

brenno commented

2026-07-24 15:35:12 +00:00

Author

Owner

Opgepakt. Tak: ci/scanners-gepind-800. Verwachte reikwijdte: .github/workflows/ci.yml (de stap "Gereedschap voor de scanners") en de beschrijving van die workflow in docs/CHECKS.md.

Opgepakt. Tak: `ci/scanners-gepind-800`. Verwachte reikwijdte: `.github/workflows/ci.yml` (de stap "Gereedschap voor de scanners") en de beschrijving van die workflow in `docs/CHECKS.md`.

brenno referenced this issue

2026-07-24 15:43:19 +00:00

Gepinde scannerversies verouderen ongemerkt — check-actions kijkt alleen naar Actions #802

brenno commented

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

Author

Owner

Bij het inbouwen kwamen er twee dingen bij, allebei in dezelfde tak ci/scanners-gepind-800:

fetch-depth: 0 op de checkout — eigen commit. De gate-taak checkte uit met de standaard van actions/checkout (één commit diep) en draaide daarna make check-secrets; twee van de vier passes daarvan gaan over de histórie (gitleaks git ., trufflehog git file://.). Op een ondiepe kloon lezen die bijna niets en eindigen groen. scans.yml had dit al (#799), alleen de GitHub-definitie liep achter. Het staat los van de pins en is daarom een aparte commit — hij kan eruit zonder de rest te raken.
De aanleiding voor test -n "\$SHA" klopt niet zoals hij in #799 is opgeschreven. 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 eindigt op 1 met "no properly formatted checksum lines found". Ook via een grep zonder treffer. De regel blijft staan, maar om een andere reden: 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. Het commentaar in ci.yml zegt dat nu; het commentaar in scans.yml verdient dezelfde correctie.

En één bevinding die hier niet in past, apart ingediend als #802: er is geen enkele bewaking die zegt dat deze drie pins verouderen. make check-actions kijkt alleen naar Actions die op een exacte versie staan, niet naar een versie in een run:-blok.

De pins zelf zijn nagelopen tegen de echte manifesten: gitleaks_8.30.1_linux_x64.tar.gz en trufflehog_3.95.9_linux_amd64.tar.gz leveren allebei een sha256 op, dus de verificatie is op deze versies geen no-op.

Bij het inbouwen kwamen er twee dingen bij, allebei in dezelfde tak `ci/scanners-gepind-800`: 1. **`fetch-depth: 0` op de checkout** — eigen commit. De gate-taak checkte uit met de standaard van `actions/checkout` (één commit diep) en draaide daarna `make check-secrets`; twee van de vier passes daarvan gaan over de histórie (`gitleaks git .`, `trufflehog git file://.`). Op een ondiepe kloon lezen die bijna niets en eindigen groen. `scans.yml` had dit al (#799), alleen de GitHub-definitie liep achter. Het staat los van de pins en is daarom een aparte commit — hij kan eruit zonder de rest te raken. 2. **De aanleiding voor `test -n "\$SHA"` klopt niet zoals hij in #799 is opgeschreven.** 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 eindigt op 1 met "no properly formatted checksum lines found". Ook via een grep zonder treffer. De regel blijft staan, maar om een andere reden: 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. Het commentaar in `ci.yml` zegt dat nu; het commentaar in `scans.yml` verdient dezelfde correctie. En één bevinding die hier niet in past, apart ingediend als #802: er is geen enkele bewaking die zegt dat deze drie pins verouderen. `make check-actions` kijkt alleen naar Actions die op een exacte versie staan, niet naar een versie in een `run:`-blok. De pins zelf zijn nagelopen tegen de echte manifesten: `gitleaks_8.30.1_linux_x64.tar.gz` en `trufflehog_3.95.9_linux_amd64.tar.gz` leveren allebei een sha256 op, dus de verificatie is op deze versies geen no-op.