LibreKAT/Ocideck
LibreKAT/Ocideck
Watch
4
0
Fork
You've already forked Ocideck
 0
Code Issues 3 Pull requests Projects Releases 4 Packages Activity Actions

Linux-releaseartefacten ondertekenen (detached signature) #1014

New issue
Closed
opened 2026-07-31 09:52:35 +00:00 by brenno · 2 comments
brenno commented 2026-07-31 09:52:35 +00:00
Owner
Copy link

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 Linux.

Stand nu

  • macOS is Developer-ID-getekend + genotariseerd (scripts/notarize_macos.sh).
  • Linux leunt uitsluitend op SHA256SUMS — in SECURITY.md uitdrukkelijk "geen handtekening". De checksum-lijst zelf is niet ondertekend, dus wie de lijst kan vervangen, kan ook de checksums vervangen.

Doel

Een detached signature (GPG of minisign) over de release-artefacten én over SHA256SUMS, met de publieke sleutel gepubliceerd op een vaste plek (repo + security.txt/website), zodat de checksum-keten een verifieerbaar anker krijgt.

Te wegen

  • GPG vs. minisign — minisign is kleiner, moderner en makkelijker te verifiëren; GPG is bekender bij distributies.
  • Sleutelbeheer en -publicatie; níet als secret in de forge-runner.
  • Reproduceerbare build als aanvullende (sterkere) route dan alleen ondertekening.

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 Linux. ## Stand nu - **macOS** is Developer-ID-getekend + genotariseerd (`scripts/notarize_macos.sh`). - **Linux** leunt uitsluitend op `SHA256SUMS` — in `SECURITY.md` uitdrukkelijk "geen handtekening". De checksum-lijst zelf is niet ondertekend, dus wie de lijst kan vervangen, kan ook de checksums vervangen. ## Doel Een detached signature (GPG of `minisign`) over de release-artefacten én over `SHA256SUMS`, met de publieke sleutel gepubliceerd op een vaste plek (repo + `security.txt`/website), zodat de checksum-keten een verifieerbaar anker krijgt. ## Te wegen - GPG vs. `minisign` — `minisign` is kleiner, moderner en makkelijker te verifiëren; GPG is bekender bij distributies. - Sleutelbeheer en -publicatie; níet als secret in de forge-runner. - Reproduceerbare build als aanvullende (sterkere) route dan alleen ondertekening. ## Verwant Onderdeel van de veilige-distributievraag #520.
brenno commented 2026-07-31 18:14:13 +00:00
Author
Owner
Copy link

Besluit: Route A — minisign (Ed25519) detached signature over SHA256SUMS, lokaal-handmatig getekend. Anders dan bij #1013 (waar ondertekening weinig oplevert) is dit goedkoop en zuiver additief, dus de keuze is: wél doen.

De vorm

  • Een detached SHA256SUMS.minisig, lokaal met de hand getekend door de beheerder — precies het model van de macOS-notarisatie (scripts/notarize_macos.sh). De private sleutel blijft bij de stichting; geen secret in de forge-runner, conform het uitgangspunt in dit issue.
  • De publieke sleutel wordt gepubliceerd op een vaste plek: in de repo (minisign.pub/KEYS), op de website, en aangewezen vanuit web/.well-known/security.txt + SECURITY.md. Een publieke sleutel is geen geheim.
  • Verifiëren: minisign -Vm SHA256SUMS -P <sleutel> (of via het KEYS-bestand).

Waarom minisign, niet GPG of SSH

  • minisign boven GPG: het project koos voor commit-ondertekening al bewust SSH boven GPG ("no keyring to manage", docs/design/GIT_STORAGE.md). minisign is dezelfde lichte smaak — één korte sleutel, geen keyring, geen web-of-trust, geen expiry-gedoe.
  • De "geen nieuwe crypto-dependency"-afweging die de zegel naar RFC 3161 duwde (docs/design/AGENTIC_BUILD_PLAN.md) geldt hier niet: release-ondertekening draait met een extern gereedschap bij het uitbrengen, niet met code in de app. minisign voegt dus geen Dart-afhankelijkheid toe.

Reikwijdte-inzicht

SHA256SUMS dekt élk bestand in de release (macOS, Windows, Linux, web, beide SBOM's). Eén handtekening over SHA256SUMS verankert daarmee de hele release — dit issue heet "Linux", maar de oplossing is platform-onafhankelijk en lost het herkomst-anker voor alle platformen tegelijk op.

Reproduceerbare build (uit "Te wegen")

De sterkere garantie (herbouw tot identieke bytes → geen vertrouwen in de bouwmachine nodig), maar een fors, apart traject; deterministische Flutter-desktopbuilds zijn lastig. Complementair aan ondertekening, geen voorwaarde. Apart, later issue — niet in deze ronde.

Uitvoeringsplan

  1. Eenmalige beheerder-stap (handmatig, buiten de repo): minisign -G om een sleutelpaar lokaal te genereren; private sleutel bewaren zoals de macOS-signing-identity/notary-profielen (keychain/veilige opslag), nooit op een runner.
  2. Repo-steiger: scripts/sign_release.sh + make sign-release dat lokaal minisign -Sm SHA256SUMS draait en de .minisig aan de release hangt; minisign.pub/KEYS in de repo; verwijzing in security.txt, SECURITY.md en de verify-instructies in .forgejo/release-body.md.
  3. Docs: SECURITY.md §"Release artifact integrity and signing", KNOWN_LIMITATIONS.md, docs/BUILD.md, release-body.md, FAQ.md bijwerken — inclusief het corrigeren van de onjuiste regel "Windows and Linux … warn on first launch" (een Linux-tarball kent geen OS-waarschuwing bij eerste start).
  4. Poort: een test die bewaakt dat de publieke sleutel gepubliceerd én aangewezen is, en dat de verify-instructie aanwezig is.
  5. Assurance: open punt O1 in assurance/enisa-sbd-mapping.md bijwerken zodra de handtekening staat.

Blokkade/volgende stap: stap 1 (sleutelpaar genereren + private-sleutelbeheer) is een handmatige beheerderactie, net als de eenmalige macOS Developer-ID/notary-opzet. Zodra de publieke sleutel bestaat, kan de rest bedraad worden.

Onderdeel van de veilige-distributievraag #520.

**Besluit: Route A — minisign (Ed25519) detached signature over `SHA256SUMS`, lokaal-handmatig getekend.** Anders dan bij #1013 (waar ondertekening weinig oplevert) is dit goedkoop en zuiver additief, dus de keuze is: wél doen. ## De vorm - Een detached `SHA256SUMS.minisig`, **lokaal met de hand getekend door de beheerder** — precies het model van de macOS-notarisatie (`scripts/notarize_macos.sh`). De private sleutel blijft bij de stichting; **geen secret in de forge-runner**, conform het uitgangspunt in dit issue. - De **publieke sleutel** wordt gepubliceerd op een vaste plek: in de repo (`minisign.pub`/`KEYS`), op de website, en aangewezen vanuit `web/.well-known/security.txt` + `SECURITY.md`. Een publieke sleutel is geen geheim. - Verifiëren: `minisign -Vm SHA256SUMS -P <sleutel>` (of via het `KEYS`-bestand). ## Waarom minisign, niet GPG of SSH - **minisign boven GPG**: het project koos voor commit-ondertekening al **bewust SSH boven GPG** ("no keyring to manage", `docs/design/GIT_STORAGE.md`). minisign is dezelfde lichte smaak — één korte sleutel, geen keyring, geen web-of-trust, geen expiry-gedoe. - De "geen nieuwe crypto-dependency"-afweging die de zegel naar RFC 3161 duwde (`docs/design/AGENTIC_BUILD_PLAN.md`) geldt hier **niet**: release-ondertekening draait met een extern gereedschap bij het uitbrengen, niet met code in de app. minisign voegt dus geen Dart-afhankelijkheid toe. ## Reikwijdte-inzicht `SHA256SUMS` dekt élk bestand in de release (macOS, Windows, Linux, web, beide SBOM's). **Eén handtekening over `SHA256SUMS` verankert daarmee de hele release** — dit issue heet "Linux", maar de oplossing is platform-onafhankelijk en lost het herkomst-anker voor alle platformen tegelijk op. ## Reproduceerbare build (uit "Te wegen") De sterkere garantie (herbouw tot identieke bytes → geen vertrouwen in de bouwmachine nodig), maar een fors, apart traject; deterministische Flutter-desktopbuilds zijn lastig. Complementair aan ondertekening, geen voorwaarde. **Apart, later issue** — niet in deze ronde. ## Uitvoeringsplan 1. **Eenmalige beheerder-stap (handmatig, buiten de repo):** `minisign -G` om een sleutelpaar lokaal te genereren; private sleutel bewaren zoals de macOS-signing-identity/notary-profielen (keychain/veilige opslag), nooit op een runner. 2. **Repo-steiger:** `scripts/sign_release.sh` + `make sign-release` dat lokaal `minisign -Sm SHA256SUMS` draait en de `.minisig` aan de release hangt; `minisign.pub`/`KEYS` in de repo; verwijzing in `security.txt`, `SECURITY.md` en de verify-instructies in `.forgejo/release-body.md`. 3. **Docs:** `SECURITY.md` §"Release artifact integrity and signing", `KNOWN_LIMITATIONS.md`, `docs/BUILD.md`, `release-body.md`, `FAQ.md` bijwerken — inclusief het **corrigeren van de onjuiste regel** "Windows **and Linux** … warn on first launch" (een Linux-tarball kent geen OS-waarschuwing bij eerste start). 4. **Poort:** een test die bewaakt dat de publieke sleutel gepubliceerd én aangewezen is, en dat de verify-instructie aanwezig is. 5. **Assurance:** open punt O1 in `assurance/enisa-sbd-mapping.md` bijwerken zodra de handtekening staat. **Blokkade/volgende stap:** stap 1 (sleutelpaar genereren + private-sleutelbeheer) is een handmatige beheerderactie, net als de eenmalige macOS Developer-ID/notary-opzet. Zodra de publieke sleutel bestaat, kan de rest bedraad worden. Onderdeel van de veilige-distributievraag #520.
brenno commented 2026-07-31 20:25:42 +00:00
Author
Owner
Copy link

Geïmplementeerd en gemerged op main — c36f406e (PR #1026).

Wat er in zit

  • De release-manifest SHA256SUMS draagt nu een minisign (Ed25519) detached signature SHA256SUMS.minisig. Eén handtekening over de lijst verankert élk artefact dat zij noemt — alle vier platformen + de SBOM's (Debian Release/Release.gpg-model).
  • Lokaal-handmatig tekenen (make sign-release → scripts/sign_release.sh): de private sleutel komt nooit als secret op een runner. Het script tekent, verifieert meteen en ruimt de handtekening op als de verify faalt.
  • Publieke sleutel minisign.pub in de repo-root, sleutel-ID 9A467E62F323426D, gepind in de poort test/release_signing_test.dart (een verwisseling laat de bouw falen). Verifiëren: minisign -Vm SHA256SUMS -p minisign.pub.
  • Docs: SECURITY.md (sleutel-ID als out-of-band anker + kruiscontrole), BUILD.md (eenmalige opzet + release-runbook), release-tekst (verify-instructie), KNOWN_LIMITATIONS/FAQ. ENISA-mapping O1 is hiermee gedicht.

Getoetst

make check groen; make check-secrets schoon; shellcheck OK; end-to-end met de echte sleutel (tekenen/verifiëren/onafhankelijke herverificatie/faal-opruiming). Twee reviews — bewaker en security-architect — beide akkoord, alle bevindingen verwerkt (o.a. de sleutel-ID als vast anker tegen de single-host-vertrouwenswortel).

Wat er bewust NIET in zit

  • Reproduceerbare build (uit "Te wegen") — de sterkere garantie, maar een fors, apart traject; het blijft als residu provenance/SLSA staan in de ENISA-mapping (O1) en verdient een eigen later issue.
  • Per-binary Windows-ondertekening (Authenticode) blijft bewust achterwege — zie #1013.

Beheerder-actiepunt

Het sleutelpaar is gegenereerd; de private helft staat lokaal (~/.minisign/ocideck-release.key) en is momenteel zonder wachtwoord. Aanrader (zie BUILD.md): zet er een wachtwoord op met minisign -C -s ~/.minisign/ocideck-release.key.

Onderdeel van de veilige-distributievraag #520.

**Geïmplementeerd en gemerged op main** — `c36f406e` (PR #1026). ## Wat er in zit - De release-manifest `SHA256SUMS` draagt nu een **minisign (Ed25519) detached signature** `SHA256SUMS.minisig`. Eén handtekening over de lijst verankert élk artefact dat zij noemt — alle vier platformen + de SBOM's (Debian `Release`/`Release.gpg`-model). - **Lokaal-handmatig tekenen** (`make sign-release` → `scripts/sign_release.sh`): de private sleutel komt nooit als secret op een runner. Het script tekent, verifieert meteen en ruimt de handtekening op als de verify faalt. - **Publieke sleutel** `minisign.pub` in de repo-root, sleutel-ID `9A467E62F323426D`, gepind in de poort `test/release_signing_test.dart` (een verwisseling laat de bouw falen). Verifiëren: `minisign -Vm SHA256SUMS -p minisign.pub`. - Docs: SECURITY.md (sleutel-ID als out-of-band anker + kruiscontrole), BUILD.md (eenmalige opzet + release-runbook), release-tekst (verify-instructie), KNOWN_LIMITATIONS/FAQ. ENISA-mapping O1 is hiermee **gedicht**. ## Getoetst `make check` groen; `make check-secrets` schoon; shellcheck OK; end-to-end met de echte sleutel (tekenen/verifiëren/onafhankelijke herverificatie/faal-opruiming). Twee reviews — **bewaker** en **security-architect** — beide akkoord, alle bevindingen verwerkt (o.a. de sleutel-ID als vast anker tegen de single-host-vertrouwenswortel). ## Wat er bewust NIET in zit - **Reproduceerbare build** (uit "Te wegen") — de sterkere garantie, maar een fors, apart traject; het blijft als residu **provenance/SLSA** staan in de ENISA-mapping (O1) en verdient een eigen later issue. - **Per-binary Windows-ondertekening** (Authenticode) blijft bewust achterwege — zie #1013. ## Beheerder-actiepunt Het sleutelpaar is gegenereerd; de private helft staat lokaal (`~/.minisign/ocideck-release.key`) en is momenteel **zonder wachtwoord**. Aanrader (zie BUILD.md): zet er een wachtwoord op met `minisign -C -s ~/.minisign/ocideck-release.key`. Onderdeel van de veilige-distributievraag #520.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
codex/markdown-editor-translations
codex/markdown-editor-ux
codex/template-followup
cockpit-wip
v0.1.3
v0.1.2
v0.1.1
v0.1.0
archive/git-mirror
Labels
Clear labels   
accepted
Assessed and will be built

  
bug
Something is broken

  
declined
Assessed and will not be built

  
docs
Documentation only

  
duplicate
Already tracked elsewhere

  
enhancement
New feature or improvement request

  
good first issue
Small, self-contained, and a good place to start

  
in-progress
Someone is working on this right now. Do not start it in parallel.

  
needs-info
Waiting for the reporter

  
privacy
Personal data can leak. Handled before anything else.

  
security
A weakness someone could use. Handled before anything else.

  
triage
Awaiting assessment

No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
LibreKAT/Ocideck#1014
No description provided.