Windows-signeerdag: de uninstaller, en drie restpunten uit de ketenjacht

brenno commented

2026-08-20 03:06:24 +00:00

Owner

Restpunten uit de adversariële jacht op de Windows-installerketen na rc1 (#1583, PR #1598). De blokkerende en stil-verkeerde bevindingen zijn in die PR gerepareerd; deze vier zijn bewust doorgeschoven, elk met de reden erbij. Let op: de toetsing van een deel van deze bevindingen is niet afgerond (de weerleggers sneuvelden op een sessielimiet) — verifieer bij het oppakken eerst aan de bron.

1. `unins000.exe` blijft ongetekend op signeerdag

De .iss zet geen SignTool-richtlijn, dus SignedUninstaller staat op no. De externe signtool-stap in scripts/build_windows_installer.sh draait ná ISCC en raakt de uninstaller niet. Op de dag dat er een certificaat is, toont verwijderen dus alsnog "Onbekende uitgever".

De route is ISCC's eigen signeerintegratie: /Ssigntool="…" op de commandoregel plus SignTool=signtool en SignedUninstaller=yes in de .iss (achter een #ifdef, zodat een bouw zonder certificaat niets merkt). Waarom uitgesteld: de quoting van zo'n geneste aanroep door bash → MSYS → ISCC is precies de klasse fout die rc1 blootlegde, en er is geen certificaat om het mee te toetsen. Dit hoort gebouwd én geproefd te worden op de dag dat het token er is, niet ervoor.

2. `LicenseFile` toont rauwe Markdown

LicenseFile=..\..\LICENSE.md compileert en werkt, maar de licentiepagina — het eerste scherm dat elke Windows-gebruiker ziet — toont het HTML-commentaar en de opmaaktekens letterlijk. Cosmetisch; de nette oplossing is een gegenereerde platte-tekst- of RTF-variant, en die generatie hoort dan wel onder een poort die hem vers houdt. Klein maar niet gratis.

3. `windows/file-associations.reg` belooft per-gebruiker, wijst naar Program Files

Het bestand zegt "per gebruiker, geen beheerdersrechten nodig", maar alle drie de paden staan hard op C:\Program Files\OciDeck\ocideck.exe — de map waar een gebruiker zónder beheerdersrechten OciDeck juist niet heeft staan. Wie de kale bundel draait moet de paden dus altijd aanpassen (het commentaar zegt dat wel, maar de belofte en de inhoud spreken elkaar tegen). Sinds de installer bestaat is de doelgroep van dit bestand kleiner; overwegen: paden vervangen door een duidelijke placeholder.

4. `publiceren` (forge): verwijderen-vóór-uploaden bij een hertrigger

Voorbestaand, los van de installer: de bijlage-vervangroute verwijdert de oude bijlage voordat de vervanger geüpload is, en leest de HTTP-code van de DELETE niet. Een gefaalde POST (een 502 op honderden MB's) laat de release dan met een gat achter; een geweigerde DELETE gaat ongemerkt vooraf aan een POST die dan botst. Netter: eerst uploaden onder een tijdelijke naam of de DELETE-status toetsen en de volgorde omdraaien waar de API dat toelaat.

Verwant

#1583 — de installer in de releaseketen (dicht)
#1013 — Authenticode bewust afgewezen; punt 1 hierboven is een voorwaarde voor het heroverwegingspad daaruit

Restpunten uit de adversariële jacht op de Windows-installerketen na rc1 (#1583, PR #1598). De blokkerende en stil-verkeerde bevindingen zijn in die PR gerepareerd; deze vier zijn bewust doorgeschoven, elk met de reden erbij. Let op: de toetsing van een deel van deze bevindingen is niet afgerond (de weerleggers sneuvelden op een sessielimiet) — verifieer bij het oppakken eerst aan de bron. ## 1. `unins000.exe` blijft ongetekend op signeerdag De `.iss` zet geen `SignTool`-richtlijn, dus `SignedUninstaller` staat op `no`. De externe signtool-stap in `scripts/build_windows_installer.sh` draait ná ISCC en raakt de uninstaller niet. Op de dag dat er een certificaat is, toont verwijderen dus alsnog "Onbekende uitgever". De route is ISCC's eigen signeerintegratie: `/Ssigntool="…"` op de commandoregel plus `SignTool=signtool` en `SignedUninstaller=yes` in de `.iss` (achter een `#ifdef`, zodat een bouw zonder certificaat niets merkt). **Waarom uitgesteld:** de quoting van zo'n geneste aanroep door bash → MSYS → ISCC is precies de klasse fout die rc1 blootlegde, en er is geen certificaat om het mee te toetsen. Dit hoort gebouwd én geproefd te worden op de dag dat het token er is, niet ervoor. ## 2. `LicenseFile` toont rauwe Markdown `LicenseFile=..\..\LICENSE.md` compileert en werkt, maar de licentiepagina — het eerste scherm dat elke Windows-gebruiker ziet — toont het HTML-commentaar en de opmaaktekens letterlijk. Cosmetisch; de nette oplossing is een gegenereerde platte-tekst- of RTF-variant, en die generatie hoort dan wel onder een poort die hem vers houdt. Klein maar niet gratis. ## 3. `windows/file-associations.reg` belooft per-gebruiker, wijst naar Program Files Het bestand zegt "per gebruiker, geen beheerdersrechten nodig", maar alle drie de paden staan hard op `C:\Program Files\OciDeck\ocideck.exe` — de map waar een gebruiker zónder beheerdersrechten OciDeck juist niet heeft staan. Wie de kale bundel draait moet de paden dus altijd aanpassen (het commentaar zegt dat wel, maar de belofte en de inhoud spreken elkaar tegen). Sinds de installer bestaat is de doelgroep van dit bestand kleiner; overwegen: paden vervangen door een duidelijke placeholder. ## 4. `publiceren` (forge): verwijderen-vóór-uploaden bij een hertrigger Voorbestaand, los van de installer: de bijlage-vervangroute verwijdert de oude bijlage voordat de vervanger geüpload is, en leest de HTTP-code van de DELETE niet. Een gefaalde POST (een 502 op honderden MB's) laat de release dan met een gat achter; een geweigerde DELETE gaat ongemerkt vooraf aan een POST die dan botst. Netter: eerst uploaden onder een tijdelijke naam of de DELETE-status toetsen en de volgorde omdraaien waar de API dat toelaat. ## Verwant - #1583 — de installer in de releaseketen (dicht) - #1013 — Authenticode bewust afgewezen; punt 1 hierboven is een voorwaarde voor het heroverwegingspad daaruit

brenno added the

enhancement

label

2026-08-20 03:06:24 +00:00

brenno referenced this issue

2026-08-20 03:06:50 +00:00

Bescherm de Windows-keten tegen MSYS-padvertaling #1598

brenno added the

in-progress

label

2026-08-20 18:57:59 +00:00

brenno referenced this issue from a commit