Podepisování desktopové aplikace a aktualizací

Podepisování desktopové aplikace není kosmetika pro antivir. Je to vazba mezi binárkou, vydavatelem a update kanálem. Projdeme certifikáty pro Windows, macOS a Linux, automatické aktualizace, CI/CD pipeline i chyby, kvůli kterým uživatelé končí u varování operačního systému.

Co podpis řeší u instalátoru a update kanálu

Digitální podpis říká dvě věci: artefakt vydal konkrétní subjekt a od podpisu se nezměnil. Neříká, že aplikace je bez chyb nebo bezpečná. Operační systém ale díky podpisu umí vyhodnotit důvěryhodnost vydavatele a uživateli nezobrazí zbytečně agresivní varování.

U desktopu podepisujete typicky instalátor, spustitelný soubor, knihovny a někdy i update manifest. U automatických aktualizací je podpis ještě důležitější: pokud útočník nahradí balíček na CDN, klient musí odmítnout update dřív, než ho spustí.

Certifikáty a politika podle operačního systému

Neexistuje jeden univerzální podpis pro všechny platformy. Windows používá Authenticode, macOS řeší Developer ID a notarizaci, Linux staví důvěru hlavně přes balíčky a repozitáře. Architektura vydávání proto musí počítat s rozdílnými artefakty.

Doporučujeme oddělit build od podpisu. Build může běžet ve standardním CI, ale privátní klíče patří do chráněného kroku s auditní stopou. U EV certifikátů nebo Apple účtu počítejte s tím, že část procesu může vyžadovat hardware token nebo specializovaný runner.

Windows: Authenticode, timestamp a reputace

Na Windows se podepisuje přes SignTool. Podepište EXE, DLL i MSI/NSIS instalátor, jinak můžete mít čistý instalátor, který po spuštění rozbalí nepodepsanou binárku. Oficiální parametry popisuje dokumentace Microsoft SignTool.

Timestamp je povinný prakticky vždy. Bez něj podpis po expiraci certifikátu ztrácí hodnotu. SmartScreen navíc pracuje s reputací vydavatele a artefaktu, takže nově vydaný certifikát může krátce zobrazovat varování i u korektně podepsané aplikace.

signtool sign ^
  /fd SHA256 ^
  /tr http://timestamp.digicert.com ^
  /td SHA256 ^
  /a dist\MyApp.exe

signtool verify /pa /v dist\MyApp.exe

macOS: Developer ID a notarizace balíčku

Na macOS samotný podpis nestačí. Pro distribuci mimo App Store používáte Developer ID Application, zapnete hardened runtime a po buildu odešlete artefakt k notarizaci. Apple postup udržuje v dokumentaci k notarizaci macOS softwaru.

Podepisujte vnitřní strukturu aplikace, ne jen výsledný DMG. Frameworky, helper procesy a binárky v .app bundle musí mít konzistentní entitlements. Gatekeeper jinak aplikaci odmítne a uživatel uvidí hlášku, kterou z podpory nechcete debugovat přes screenshoty.

codesign --deep --force --options runtime \
  --sign "Developer ID Application: Example s.r.o." \
  dist/mac/MyApp.app

xcrun notarytool submit dist/MyApp.dmg \
  --keychain-profile "notary-profile" \
  --wait

xcrun stapler staple dist/MyApp.dmg

Linux: balíček, repozitář a samostatná důvěra

Linux nemá jeden centrální model důvěry. U Debian/Ubuntu řešíte APT repozitář a GPG podpis metadat, u RPM zase podpis balíčku a repozitáře. AppImage často kombinuje podpis souboru s vlastním update mechanismem.

Pro interní firemní distribuci bývá nejlepší vlastní repozitář. Uživatel nainstaluje veřejný klíč jednou a dál dostává aktualizace standardní cestou správce balíčků. Pro veřejný B2C desktop je potřeba zvážit, jestli Linux vůbec potřebuje auto-update mimo balíčkovací ekosystém.

Build pipeline: podepsat artefakt, ne zdrojový kód

CI/CD pro podepisování desktopové aplikace má mít reprodukovatelný build, oddělený signing krok a publikaci až po verifikaci. Prakticky to znamená: build vytvoří artefakty, signing job je podepíše a další job ověří podpis nezávislým příkazem.

Privátní klíč nikdy neukládejte do repozitáře ani do běžné proměnné bez omezení. Použijte KMS, HSM, chráněné secrets v CI nebo dedikovaný podepisovací stroj. Důležité je také verzovat manifest vydání, hash artefaktů a přesný commit, ze kterého release vznikl.

release:
  steps:
    - build: "npm run dist"
    - sign: "platform-specific signing job"
    - verify: "check signatures and notarization status"
    - publish: "upload artifacts and signed update manifest"
  safeguards:
    - protected_branch
    - manual_approval
    - immutable_artifacts

Pokud stavíme desktop nad webovou technologií, typicky řešíme i balení Electronu, systémové integrace a aktualizace. U zakázkového vývoje dává smysl řešit to společně s produkční architekturou, ne až těsně před releasem; víc k našemu přístupu je na stránce vývoj desktopových aplikací.

Auto-update: podpis manifestu je stejně důležitý

Automatická aktualizace je vzdálené spuštění kódu s pohodlným UI. Proto nestačí podepsat jen instalační balíček. Klient musí stáhnout manifest, ověřit jeho podpis, zkontrolovat hash balíčku a teprve potom update rozbalit nebo spustit.

U nativního macOS je běžná knihovna Sparkle pro aktualizace aplikací. Electron projekty často používají electron-builder a electron-updater. V obou případech si ohlídejte, kde leží klíče, jak se podepisuje feed a co se stane při rollbacku.

{
  "version": "1.8.4",
  "files": [
    {
      "url": "MyApp-1.8.4-x64.exe",
      "sha512": "base64-encoded-hash",
      "size": 82411264
    }
  ],
  "signature": "detached-signature-over-manifest"
}

Rollout dělejte po vlnách. Nejdřív interní kanál, potom malé procento uživatelů a až nakonec plný release. Update klient musí umět odmítnout downgrade, neplatný podpis, nekompatibilní architekturu a přerušené stažení bez poškození instalace.

Kontrolní seznam před vydáním nové verze

Před publikací ověřte instalaci na čistém stroji bez vývojářských certifikátů. Testujte Windows SmartScreen, macOS Gatekeeper i odinstalaci starší verze. Nestačí spustit aplikaci z build složky, protože produkční problém bývá často v instalátoru nebo oprávněních.

Do release checklistu patří podpis všech binárek, timestamp, notarizace, hash artefaktů, validní update manifest, rollback plán a monitoring chyb po vydání. Pokud se mění auto-update kód, berte release jako rizikovější než běžnou funkční úpravu.

U více platforem držte jednotné číslování verzí, ale nesnažte se za každou cenu vydat všechny balíčky ve stejnou minutu. Lepší je zadržet jeden artefakt kvůli chybě v podpisu než publikovat neověřený build a následně řešit ruční opravy u zákazníků.

Co si odnést pro bezpečné vydávání verzí

Dobře navržené podepisování desktopové aplikace není jeden příkaz v CI. Je to proces kolem certifikátů, ochrany klíčů, ověření artefaktů a bezpečného update kanálu. Když ho uděláte správně, uživatelé instalují bez varování a vy máte kontrolu nad každou verzí.

Největší přínos je provozní klid. Release není ruční rituál na jednom notebooku, ale opakovatelná pipeline s dohledatelným původem binárek. To je rozdíl mezi aplikací, která jde bezpečně škálovat, a produktem, kde se každý update odkládá ze strachu.