Gitpervisor

Code Signing Policy

Gitpervisor is an open-source desktop application distributed as prebuilt installers. This page documents how those installers are produced and signed, who is allowed to approve a signature, and how you can verify a download yourself without trusting this page.

What gets signed

Every release artifact is built from the public source at imtelloper/gitpervisor and published to GitHub Releases. Two independent signatures are involved, and they serve different purposes:

  • Authenticode (Windows). The Windows installer Gitpervisor_<version>_x64-setup.exe carries a Windows code signature so the operating system and anti-malware products can attribute it to a known publisher.
  • Update signatures (all platforms). Every artifact is additionally signed with a project-held minisign key. The in-app updater refuses any download whose signature does not match the public key compiled into the application, so a tampered release cannot be pushed to existing installations.

Linux packages (.deb, .rpm, .AppImage) and the macOS bundle carry the update signature only.

How releases are built

Releases are never built or uploaded from a developer machine. A release is produced entirely by a GitHub Actions workflow that is itself part of the versioned source tree, and it runs only on GitHub-hosted runners.

  1. A maintainer pushes a v* tag to the default branch.
  2. The workflow checks out that exact commit and builds each platform from source.
  3. The build submits the artifact for signing. The signing service independently verifies the origin of the request — repository, branch, commit, and workflow run — before a signature can be issued.
  4. Signed artifacts, their update signatures, and the update manifest are attached to the release.

Because the build configuration lives in the repository, any change to how a release is produced is a reviewable commit in public history.

Roles and approval

Gitpervisor is currently maintained by a single developer, imtelloper, who acts as author, reviewer, and approver. We state this plainly rather than implying a separation of duties that does not exist. These controls apply:

  • Multi-factor authentication is required on the GitHub account that can push tags and on the signing service account.
  • Every signing request is approved individually and manually. There is no unattended or bulk signing.
  • Signing certificates are held by the signing service and are never present on a developer machine, so they cannot be exfiltrated from one.
  • Only artifacts built by the release workflow from this repository are ever submitted for signing.

If additional maintainers join, this page will be updated to separate the reviewer and approver roles.

Verifying a download

You do not have to take any of this on trust. On Windows, check the signature of the installer you downloaded:

Get-AuthenticodeSignature .\Gitpervisor_<version>_x64-setup.exe |
  Format-List Status, SignerCertificate

Status must read Valid. A result of NotSigned, HashMismatch, or an unexpected signer means the file was not produced by this project's release pipeline — do not run it, and please report it.

On every platform you can compare the file you downloaded against the assets listed on the release page, and reproduce the build yourself from the tagged commit.

Publisher name

Free code signing for open-source projects is provided by certificate authorities and foundations that issue the certificate in their own name. As a result, the publisher shown by Windows may be the issuing foundation rather than Gitpervisor or imtelloper. This is expected and is not a sign of tampering. The authoritative check is that the signature status is valid and the file came from the release page linked above.

Reporting misuse or vulnerabilities

If you believe a signed Gitpervisor binary is malicious, has been tampered with, or that a signature has been misused, report it at imtelloper/gitpervisor/issues. For anything you would rather not disclose publicly, use GitHub's private security advisory form on the repository's Security tab.

We will investigate any credible report, cooperate with the certificate issuer, and request revocation of an affected signature where warranted.

Current status

Windows Authenticode signing is being introduced. Releases up to and including v0.3.5 are unsigned on Windows, which is why SmartScreen and some anti-malware products warn about them or delay the install while they scan. Update signatures have been present on all platforms since the updater shipped and are unaffected.

This page will state the active signing provider and the first signed version once the first signed release is published.

Last updated 2026-08-04. This policy is versioned with the source; see its history in the repository.