Sign the binaries on macOS and windows

[0xbrayo]

Signing seems pretty straight forward for both windows and macos.

[0xbrayo]

@ErikBjare I don't have access to the signing keys, could you handle this one?

[0xbrayo]

Or just set the secrets I'll do the rest :)

[roke-julian-lockhart]

@0xbrayo, per security.stackexchange.com/questions/138651/does-linux-support-signed-binaries#comment591549_138651, this may at least be possible on Linux, too.

However, better to sign the packages (at least, so that PackageKit doesn't stupidly consider them to be uninstallable). Does an issue track that?

[0xbrayo]

Signing on linux is low priority, but I'll look into it :)

[0xbrayo]

@TimeToBuildBob could you check into linux signing, can this be done in the AW parent repo?

[TimeToBuildBob]

Hey @0xbrayo, looked into this.

Linux signing landscape: Unlike macOS (codesign + notarization) and Windows (Authenticode), Linux doesn't have a single dominant binary signing mechanism. The practical approaches are:

• Package-level signing: .deb packages via dpkg-sig/debsign, .rpm via rpm --addsign. This is what distro package managers verify.
• AppImage: appimagetool --sign supports GPG signing, and AppImageUpdate can verify signatures.
• Flatpak: Signing is built into the Flatpak/OSTree publishing flow.
• Raw ELF binaries: Technically possible (Linux kernel supports sign-file), but no userspace tooling widely verifies this.

Tauri-specific: Tauri's built-in updater signing (used for macOS/Windows) doesn't extend to Linux. For .deb/.AppImage outputs, signing would need to be a post-build CI step.

Where it should live: Since the Tauri build (and thus the Linux artifact generation) happens in aw-tauri, the signing step would naturally live here in the release workflow. The parent activitywatch repo orchestrates the final release, but the actual artifacts are built per-platform in aw-tauri CI.

As @0xbrayo noted, this is low priority — happy to help set it up when the macOS/Windows signing is stable and we're ready to tackle Linux.

[TimeToBuildBob]

Looked into this. Linux binary signing is technically feasible in GitHub Actions:

• AppImage: Can be GPG-signed via appimagetool --sign with a private key stored as a GitHub Actions secret
• .deb packages: Can be signed with dpkg-sig or by setting up a signed APT repo
• Workflow placement: Could live in either aw-tauri or the AW parent repo — both work. Since my PR feat: add aw-tauri CI builds alongside aw-qt activitywatch#1209 already adds aw-tauri CI builds to the parent repo, it would be natural to centralize signing there too.

Blocker: The signing keys need to be set up as GitHub Actions secrets in whichever repo handles the release builds. Without the keys, I can write the workflow but it can't run.

If Erik (@ErikBjare) can set up a GPG signing key pair and store the private key as a secret (e.g. LINUX_SIGNING_KEY), I can write the workflow step. Alternatively, if Linux signing is still low priority, we can defer and focus on macOS/Windows first.

[ErikBjare]

macOS signing is now set up for the ActivityWatch main repo/bundle since ActivityWatch/activitywatch#1260 (not very well tested, but passes the signing itself)

Working on getting the first v0.14 beta out which would contain it

[TimeToBuildBob]

Code signing findings

Completed a research pass. Summary below; full doc in Bob's workspace at knowledge/activitywatch/aw-tauri-code-signing-findings.md.

Current state

release.yml uses tauri-apps/tauri-action@v0 with no signing env vars — all platforms produce unsigned binaries.

macOS

• Cost: $0 additional — same Developer ID certificate Erik already has for the main activitywatch repo (PR #1260)
• Just needs the cert exported as base64 + a few Apple ID secrets added to the aw-tauri repo settings
• Standard Tauri env vars: APPLE_CERTIFICATE, APPLE_CERTIFICATE_PASSWORD, APPLE_SIGNING_IDENTITY, APPLE_ID, APPLE_PASSWORD, APPLE_TEAM_ID

Windows

• Recommended: Azure Trusted Signing free OSS tier — $0/year, 1–3 day setup for org verification
• Alternative: EV cert from Sectigo/DigiCert (~$300–500/year)
• Azure option requires: Azure subscription + Trusted Signing resource + azure/trusted-signing-action@v0 in CI

Action items for Erik

1. Export the existing Developer ID cert → add to aw-tauri repo secrets as APPLE_CERTIFICATE + related Apple vars
2. Apply for Azure Trusted Signing OSS tier at portal.azure.com
3. Once secrets exist, I can write the PR to update release.yml (should be ~10 lines)

@ErikBjare — the macOS part is essentially free and reuses what you already have. Windows just needs the Azure account setup.