LibreKAT/Ocideck

Watch

Fork 0

Windows-releaseartefacten ondertekenen (Authenticode) #1013

New issue

Closed

opened 2026-07-31 09:52:34 +00:00 by brenno · 1 comment

brenno commented

2026-07-31 09:52:34 +00:00

Owner

Voortgekomen uit de ENISA Secure-by-Design-afbeelding (assurance/enisa-sbd-mapping.md, open punt O1 — playbook 14, "release artefacts signed"). Eén issue per onbehandeld platform; dit is Windows.

Stand nu

Artefactondertekening is asymmetrisch:

macOS is Developer-ID-getekend + genotariseerd (scripts/notarize_macos.sh, make notarize-macos).
Windows leunt uitsluitend op SHA256SUMS — in SECURITY.md uitdrukkelijk "geen handtekening". SmartScreen waarschuwt daardoor bij uitvoeren.

Doel

Authenticode-ondertekening van het Windows-artefact, zodat het herkomst heeft en SmartScreen niet meer waarschuwt.

Te wegen

Certificaat: EV vs. OV, kosten, en of een stichting er een op naam kan krijgen.
Waar de sleutel woont — bij voorkeur níet als secret in de forge-runner (past bij het least-privilege-uitgangspunt); handmatige ondertekeningsstap in de release-keten is een geldige uitkomst.
Of dit haalbaar/gewenst is gegeven de kernwaarde "de gebruiker bouwt uit de bron" — ondertekening is een toevoeging voor wie het binaire artefact gebruikt, geen vervanging van de bronroute.

Verwant

Onderdeel van de veilige-distributievraag #520.

Voortgekomen uit de ENISA Secure-by-Design-afbeelding (`assurance/enisa-sbd-mapping.md`, open punt O1 — playbook 14, "release artefacts signed"). Eén issue per onbehandeld platform; dit is Windows. ## Stand nu Artefactondertekening is asymmetrisch: - **macOS** is Developer-ID-getekend + genotariseerd (`scripts/notarize_macos.sh`, `make notarize-macos`). - **Windows** leunt uitsluitend op `SHA256SUMS` — in `SECURITY.md` uitdrukkelijk "geen handtekening". SmartScreen waarschuwt daardoor bij uitvoeren. ## Doel Authenticode-ondertekening van het Windows-artefact, zodat het herkomst heeft en SmartScreen niet meer waarschuwt. ## Te wegen - Certificaat: EV vs. OV, kosten, en of een stichting er een op naam kan krijgen. - Waar de sleutel woont — bij voorkeur níet als secret in de forge-runner (past bij het least-privilege-uitgangspunt); handmatige ondertekeningsstap in de release-keten is een geldige uitkomst. - Of dit haalbaar/gewenst is gegeven de kernwaarde "de gebruiker bouwt uit de bron" — ondertekening is een toevoeging voor wie het binaire artefact gebruikt, geen vervanging van de bronroute. ## Verwant Onderdeel van de veilige-distributievraag #520.

brenno added the

enhancement

security

labels

2026-07-31 09:52:34 +00:00

brenno referenced this issue from a commit

2026-07-31 09:55:36 +00:00

docs(assurance): ENISA-mapping — open punten wegen, issues koppelen

brenno referenced this issue

2026-07-31 09:55:52 +00:00

docs(assurance): ENISA-mapping — open punten wegen en aan issues koppelen #1016

brenno commented

2026-07-31 17:46:04 +00:00

Author

Owner

Besluit: geen Authenticode-ondertekening — bewust aanvaard als grens. Na afweging van de drie routes (niets doen / OV-cert handmatig-lokaal / Azure Trusted Signing in CI) valt de keuze op aanvaarden en documenteren.

Waarom

Het kantelpunt zit in de drie "te wegen"-punten:

EV vs. OV. Sinds maart 2024 heeft Microsoft de aparte SmartScreen-status van EV geschrapt: EV én OV bouwen nu identiek reputatie op via downloadvolume. Een EV-certificaat kopen om SmartScreen meteen te laten zwijgen is niet meer zinvol (EV telt nog voor kernel-drivers/enterprise-inkoop — niet voor ons). En sinds juni 2023 moet elke private sleutel op hardware/HSM staan. Gevolg: geen enkel certtype laat SmartScreen direct zwijgen. Het doel "SmartScreen niet meer waarschuwt" is nu alleen geleidelijk en downloadvolume-afhankelijk haalbaar — bij een niche-tool traag. De baten van tekenen zijn daarmee veel kleiner dan het doel suggereerde.
Waar de sleutel woont. Elke betaalde route brengt óf jaarlijkse kosten + org-validatie + een hardware-token (OV, lokaal-handmatig), óf een clouddienst met credentials als secret in de release-runner (Azure Trusted Signing). Dat laatste botst frontaal met het least-privilege-uitgangspunt uit dit issue en brengt bovendien een cloudafhankelijkheid in de release-keten.
Kernwaarde "bouw uit de bron". Ondertekening is een toevoeging voor wie het binaire artefact gebruikt, geen vervanging van de bronroute — en de bronroute blijft de echte herkomstgarantie. Bij het huidige batenbeeld (geen directe SmartScreen-winst) wegen de terugkerende kosten en/of de afhankelijkheid daar niet tegenop.

Wat blijft gelden

Het Windows-artefact leunt op SHA256SUMS, met een expliciete "More info → Run anyway"-uitleg. Dat staat al correct in .forgejo/release-body.md, docs/BUILD.md, docs/FAQ.md en docs/KNOWN_LIMITATIONS.md — geen documentatiewijziging nodig.

Heroverweging

Groeit het downloadvolume ooit, of wordt de SmartScreen-waarschuwing een reëel bezwaar, dan is Route B de aangewezen weg: een OV-certificaat op naam van Stichting LibreKAT, op een hardware-token, met een handmatige signeerstap — precies het model van de macOS-notarisatie (scripts/notarize_macos.sh), zonder secret in enige runner. Azure Trusted Signing blijft afgeraden vanwege de cloudafhankelijkheid en het runner-secret.

Relatie

#1014 (Linux, detached signature) blijft een aparte open afweging.
ENISA O1 (assurance/enisa-sbd-mapping.md, playbook 14): de Windows-tak is hiermee "bewust aanvaard"; O1 als geheel blijft open zolang #1014 loopt.
Onderdeel van de veilige-distributievraag #520.

**Besluit: geen Authenticode-ondertekening — bewust aanvaard als grens.** Na afweging van de drie routes (niets doen / OV-cert handmatig-lokaal / Azure Trusted Signing in CI) valt de keuze op aanvaarden en documenteren. ## Waarom Het kantelpunt zit in de drie "te wegen"-punten: - **EV vs. OV.** Sinds **maart 2024** heeft Microsoft de aparte SmartScreen-status van EV geschrapt: EV én OV bouwen nu identiek reputatie op via **downloadvolume**. Een EV-certificaat kopen om SmartScreen meteen te laten zwijgen is niet meer zinvol (EV telt nog voor kernel-drivers/enterprise-inkoop — niet voor ons). En sinds juni 2023 moet elke private sleutel op hardware/HSM staan. **Gevolg: geen enkel certtype laat SmartScreen direct zwijgen.** Het doel "SmartScreen niet meer waarschuwt" is nu alleen geleidelijk en downloadvolume-afhankelijk haalbaar — bij een niche-tool traag. De baten van tekenen zijn daarmee veel kleiner dan het doel suggereerde. - **Waar de sleutel woont.** Elke betaalde route brengt óf jaarlijkse kosten + org-validatie + een hardware-token (OV, lokaal-handmatig), óf een clouddienst met credentials als **secret in de release-runner** (Azure Trusted Signing). Dat laatste botst frontaal met het least-privilege-uitgangspunt uit dit issue en brengt bovendien een cloudafhankelijkheid in de release-keten. - **Kernwaarde "bouw uit de bron".** Ondertekening is een toevoeging voor wie het binaire artefact gebruikt, geen vervanging van de bronroute — en de bronroute blijft de echte herkomstgarantie. Bij het huidige batenbeeld (geen directe SmartScreen-winst) wegen de terugkerende kosten en/of de afhankelijkheid daar niet tegenop. ## Wat blijft gelden Het Windows-artefact leunt op `SHA256SUMS`, met een expliciete "More info → Run anyway"-uitleg. Dat staat al correct in `.forgejo/release-body.md`, `docs/BUILD.md`, `docs/FAQ.md` en `docs/KNOWN_LIMITATIONS.md` — geen documentatiewijziging nodig. ## Heroverweging Groeit het downloadvolume ooit, of wordt de SmartScreen-waarschuwing een reëel bezwaar, dan is **Route B** de aangewezen weg: een OV-certificaat op naam van Stichting LibreKAT, op een hardware-token, met een handmatige signeerstap — precies het model van de macOS-notarisatie (`scripts/notarize_macos.sh`), zonder secret in enige runner. Azure Trusted Signing blijft afgeraden vanwege de cloudafhankelijkheid en het runner-secret. ## Relatie - **#1014** (Linux, detached signature) blijft een aparte open afweging. - **ENISA O1** (`assurance/enisa-sbd-mapping.md`, playbook 14): de Windows-tak is hiermee "bewust aanvaard"; O1 als geheel blijft open zolang #1014 loopt. - Onderdeel van de veilige-distributievraag **#520**.

brenno closed this issue

2026-07-31 17:46:06 +00:00

brenno referenced this issue from a commit

2026-07-31 18:12:16 +00:00

docs(assurance): O1 Windows-tak aanvaard, ondertekeningsbesluit uitgelegd

brenno referenced this issue

2026-07-31 18:12:43 +00:00

docs(assurance): O1 Windows-tak aanvaard — ondertekeningsbesluit uitgelegd #1020

brenno referenced this issue

2026-07-31 18:14:13 +00:00

Linux-releaseartefacten ondertekenen (detached signature) #1014

brenno referenced this issue