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 :)

[RokeJulianLockhart]

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