security(windows): honoreert native git op Windows sslCAInfo/curloptResolve? (NetGuard-pin op de subproces-weg) #934

New issue

Closed

opened 2026-07-27 23:14:49 +00:00 by brenno · 1 comment

brenno commented

2026-07-27 23:14:49 +00:00

Owner

Afgesplitst van #926 als open beveiligingsvraag die daar niet te beantwoorden was.

De vraag

De NetGuard-belofte op de native git-weg (subproces-git) leunt erop dat git twee configuraties daadwerkelijk honoreert:

http.sslCAInfo — een zelfondertekend certificaat als geldig anker, mét behoud van de naamcontrole (cert-pinning);
http.curloptResolve — de bestemming pinnen op een goedgekeurd adres (host-pinning), plus http.followRedirects=false.

Op macOS/Linux is dit getoetst met echte git tegen een lokale HTTPS-testserver (git_native_cert_pin_test.dart, git_network_guard_test.dart). Op Windows komt die verbinding op de CI-runner niet eens tot stand, en gebruikt git doorgaans schannel in plaats van openssl/curl — waar sslCAInfo (een CA-bestand) anders of niet werkt, en waar curloptResolve een curl-optie is die van de gekozen http-backend afhangt.

In #928 zijn die twee echt-server-tests daarom op Windows overgeslagen mét reden. De argv/config die de app meegeeft is op Windows wél gedekt door de zustertests; wat níet geverifieerd is, is of gít zich er op Windows aan houdt.

Wat nodig is

Verificatie op een echte Windows-machine (niet enkel de CI groen maken): welke http-backend gebruikt de meegeleverde/gangbare git op Windows, en honoreert die sslCAInfo en curloptResolve? Zo niet, dan is de pin op de native git-weg op Windows een papieren maatregel en moet er een schannel-equivalent (of een andere afdwinging) komen.

Geen acute lekkage: de app draait de native git-weg alleen bij een expliciet ingerichte git-opslag, en de overige guards (schema-weigering, privaat-adres-blokkade, geen token over plat http) gelden platformbreed.

Afgesplitst van #926 als open beveiligingsvraag die daar niet te beantwoorden was. ## De vraag De NetGuard-belofte op de **native git-weg** (subproces-git) leunt erop dat git twee configuraties daadwerkelijk honoreert: - `http.sslCAInfo` — een zelfondertekend certificaat als geldig anker, mét behoud van de naamcontrole (cert-pinning); - `http.curloptResolve` — de bestemming pinnen op een goedgekeurd adres (host-pinning), plus `http.followRedirects=false`. Op macOS/Linux is dit getoetst met echte git tegen een lokale HTTPS-testserver (`git_native_cert_pin_test.dart`, `git_network_guard_test.dart`). Op **Windows** komt die verbinding op de CI-runner niet eens tot stand, en gebruikt git doorgaans **schannel** in plaats van openssl/curl — waar `sslCAInfo` (een CA-bestand) anders of niet werkt, en waar `curloptResolve` een curl-optie is die van de gekozen http-backend afhangt. In #928 zijn die twee echt-server-tests daarom op Windows overgeslagen mét reden. De argv/config die de app meegeeft is op Windows wél gedekt door de zustertests; wat níet geverifieerd is, is of gít zich er op Windows aan houdt. ## Wat nodig is Verificatie op een **echte Windows-machine** (niet enkel de CI groen maken): welke http-backend gebruikt de meegeleverde/gangbare git op Windows, en honoreert die `sslCAInfo` en `curloptResolve`? Zo niet, dan is de pin op de native git-weg op Windows een papieren maatregel en moet er een schannel-equivalent (of een andere afdwinging) komen. Geen acute lekkage: de app draait de native git-weg alleen bij een expliciet ingerichte git-opslag, en de overige guards (schema-weigering, privaat-adres-blokkade, geen token over plat http) gelden platformbreed.

brenno added the

security

label

2026-07-27 23:14:49 +00:00

brenno referenced this issue

2026-07-27 23:15:06 +00:00

fix(test): Windows-testleg op de spiegel-CI groen (padscheiding, spawn-milieu, mock-contracten) #926

brenno added the

in-progress

label

2026-07-28 00:12:29 +00:00

brenno referenced this issue from a pull request that will close it,

2026-07-28 00:26:00 +00:00

security(windows): make the native-git TLS pins hold — and prove them — on Windows (#934) #939

brenno referenced this issue from a commit

2026-07-28 00:28:42 +00:00

security(windows): force openssl backend on the native-git cert pin

brenno referenced this issue from a commit

2026-07-28 00:28:42 +00:00

test(git): run the native-git pin tests on Windows CI (#934)

brenno commented

2026-07-28 01:38:13 +00:00

Author

Owner

Opgelost en op main.

curloptResolve (host-pin): git honoreert dit óók op Windows — het is een libcurl-optie (CURLOPT_RESOLVE), los van de TLS-backend. Dat de echt-server-toets eerder "niet verbond" op de Windows-CI lag aan de omgeving van díe test (geen SystemRoot → geen socket-DLL), niet aan git.

sslCAInfo (cert-pin): dít was op Windows wél een papieren maatregel. Git-for-Windows kiest standaard schannel, en die negeert http.sslCAInfo (de installer haalt hem er zelfs uit). Opgelost door op de gepinde weg de openssl-backend te forceren (pinnedCertBackendConfig), zodat git tegen precies ons CA-bestand valideert — het gedrag dat op macOS/Linux al bewezen was. Alleen op de gepinde weg; een publieke-CA-server houdt schannel + de Windows-certificaatlade.

De twee echt-server-toetsen draaien nu óók op windows-2022 (met een Windows-correcte omgeving) in plaats van overgeslagen. Empirisch groen op de runner:

✅ git_native_cert_pin_test: git accepteert het certificaat met sslCAInfo, en zonder niet
✅ git_network_guard_test: curloptResolve verlegt de bestemming

Op main in cc359f2a (fix + SECURITY_DESIGN §10) en 4d649110 (Windows-CI-toetsen + unit test). CI-run: https://github.com/brennodewinter/Ocideck/actions/runs/30317415087

Opgelost en op main. **curloptResolve (host-pin):** git honoreert dit óók op Windows — het is een libcurl-optie (CURLOPT_RESOLVE), los van de TLS-backend. Dat de echt-server-toets eerder "niet verbond" op de Windows-CI lag aan de omgeving van díe test (geen `SystemRoot` → geen socket-DLL), niet aan git. **sslCAInfo (cert-pin):** dít was op Windows wél een papieren maatregel. Git-for-Windows kiest standaard schannel, en die negeert `http.sslCAInfo` (de installer haalt hem er zelfs uit). Opgelost door op de gepinde weg de openssl-backend te forceren (`pinnedCertBackendConfig`), zodat git tegen precies ons CA-bestand valideert — het gedrag dat op macOS/Linux al bewezen was. Alleen op de gepinde weg; een publieke-CA-server houdt schannel + de Windows-certificaatlade. De twee echt-server-toetsen draaien nu óók op **windows-2022** (met een Windows-correcte omgeving) in plaats van overgeslagen. Empirisch groen op de runner: - ✅ `git_native_cert_pin_test`: *git accepteert het certificaat met sslCAInfo, en zonder niet* - ✅ `git_network_guard_test`: *curloptResolve verlegt de bestemming* Op main in `cc359f2a` (fix + SECURITY_DESIGN §10) en `4d649110` (Windows-CI-toetsen + unit test). CI-run: https://github.com/brennodewinter/Ocideck/actions/runs/30317415087

brenno closed this issue

2026-07-28 01:38:13 +00:00

brenno referenced this issue

2026-07-28 01:38:23 +00:00

security(windows): make the native-git TLS pins hold — and prove them — on Windows (#934) #939