menu
save_alt Λήψη

Binary Distribution & Code Signing Policy

Internal procedures for signing and distributing application binaries

< Back

Purpose

Define the internal procedures staff must follow when signing, notarizing, and distributing Beekeeper Studio application binaries.

1. Scope

This policy applies to all staff involved in releasing Beekeeper Studio desktop application builds for:

  • Windows (installer and portable builds)
  • macOS (DMG and zip builds)
  • Linux (AppImage, deb, rpm, and snap builds)

2. Build Pipeline Requirements

  • Never produce release artifacts on a developer machine. All release builds must be triggered by tagged commits and run in CI (GitHub Actions).
  • Retain build logs and artifacts for a minimum of 12 months.
  • Follow the Change Management Policy - every release must originate from a reviewed and merged PR, tagged on main.
  • Before tagging a release, verify that all CI checks pass and the changelog is up to date.

3. Code Signing Procedures

3.1 Windows - EV Code Signing Certificate

  • Sign all Windows release binaries using our Extended Validation (EV) code signing certificate.
  • The EV certificate private key is stored in hardware-backed storage via the signing service - do not attempt to export or copy it.
  • Signing runs automatically in CI. If the signing step fails, do not publish unsigned binaries. Investigate and resolve the failure before re-running.
  • After a release, spot-check the published installer: right-click → Properties → Digital Signatures and confirm the signer matches our legal entity name.

3.2 macOS - Apple Notarization

  • Sign all macOS release binaries with our Apple Developer ID certificate.
  • After signing, CI submits the build to Apple’s notarization service. Wait for notarization to complete - do not distribute builds that have not been notarized.
  • CI staples the notarization ticket to the binary. Verify stapling succeeded by running stapler validate on the artifact.
  • If notarization is rejected, review Apple’s response log, fix the flagged issue, and rebuild. Do not override Gatekeeper warnings manually.

3.3 Linux - GPG Signing

  • Sign all Linux release packages using our release GPG key.
  • The GPG private key is stored as a CI secret - do not store copies on developer machines.
  • Ensure the corresponding public key is published and accessible so users and package managers can verify signatures.
  • Snap packages are additionally signed through the Snap Store’s own infrastructure upon upload.

4. Distribution Channels

Publish signed artifacts to the following channels for each release:

Channel Platform Responsible Action
GitHub Releases All Upload all platform artifacts to the tagged release
Snap Store Linux Push the signed snap package
Homebrew Cask macOS Update the cask formula with the new version and SHA
Winget Windows Submit a manifest update to the winget-pkgs repository
APT repository Linux (deb) Publish the signed deb to the repository
  • All channels must serve the same CI-built, signed artifacts. Never rebuild separately for a specific channel.
  • After publishing, verify that at least one download from each channel installs and launches correctly.

5. Key & Certificate Management

  • Storage: All signing keys and certificates are stored as encrypted CI secrets or in hardware-backed key storage. No signing credentials may be stored on developer machines, in chat, or in source control.
  • Access: Only the CI pipeline and designated release managers may access signing credentials. Access requires multi-factor authentication.
  • Rotation: Track certificate and key expiry dates. Begin renewal at least 30 days before expiry. Document the renewal in the internal changelog.
  • Revocation: If a signing key is suspected to be compromised, revoke it immediately, notify the team, and issue a new key. Re-sign and re-publish the most recent release with the new key.

6. Incident Procedures

  • If an unsigned or incorrectly signed binary is published, pull it from all distribution channels immediately and re-publish a correctly signed build.
  • If a signing key or certificate is compromised, follow the revocation steps in Section 5 and file an incident per the Incident Response Plan.

7. Review

This policy is reviewed annually or whenever signing infrastructure, CI providers, or distribution channels change. All staff involved in the release process must acknowledge updates.