Code signing policy
The Windows downloads in GitHub 1.5.1 are code-signed and timestamped as MASTERPANEL LLC using Microsoft Azure Artifact Signing. This covers the x64, ARM64 and universal installers, and the portable x64 executable. Get them from the official release page. Microsoft documents Artifact Signing here.
Windows signing began with version 1.5.1. The older 1.5.0 direct Windows files remain unsigned; their release history has not been rewritten. Linux packages do not carry a platform code signature. Their verification uses SHA-256 checksums, the Sigstore signature over the checksum list, and build provenance.
A valid code signature identifies the publisher and protects the signed bytes. It does not guarantee that SmartScreen stops warning. Microsoft now documents that unsigned, self-signed and newly signed files can receive reputation warnings. Extended Validation certificates no longer bypass the reputation process. Signing identifies a publisher and protects signed bytes; it is not a guarantee of safe behavior. Check the publisher alongside the release's checksums and attestation.
What carries a signature, and what does not#
Windows Authenticode signing is separate from the release evidence shared by
Windows and Linux. Starting with version 1.5, the release workflow signs
SHA256SUMS.txt with Sigstore and
publishes build provenance for the artifacts. Those records identify this
project's public workflow and the exact tag in
this repository; they are not a
conventional signature on the executable itself.
The Microsoft Store package is separate. Microsoft re-signs the MSIX/AppX package it distributes. Windows verifies that package during installation. This does not individually code-sign every executable inside it. The download page explains the two distribution channels.
Team roles#
- Committers and reviewers
- People granted write or review access to the repository. The organisation does not publish a member roster, so its public people page is not used as identity evidence. Commits, pull-request reviews and workflow runs that actually happen remain visible in the public repository.
- Approvers
- People with permission to create a release tag and run the release workflow. Those GitHub roles are not publicly enumerated. The named publisher accountable for the product and its releases is MASTERPANEL LLC.
- Multi-factor authentication
- Our policy requires it for every person in both roles on GitHub. This is a publisher policy statement: GitHub's private membership and account-security settings are not public evidence that every account complies. MFA reduces password-only compromise; stolen sessions, tokens and compromised workflows remain risks that MFA alone does not remove.
Privacy#
No ODA backend. No ODA account. No cloud sync. No telemetry. User-requested Steam operations contact Valve. In direct GitHub builds, the optional update check contacts GitHub; Microsoft Store builds do not perform that check. The user-driven browser contacts the sites the user chooses and the third-party resources those pages load. Visiting our site through that browser is also covered by the website portion of the privacy policy. The full privacy policy is here, and the security page describes what the application stores and where.
Verifying a release#
A code signature identifies who signed an executable; it does not identify which
source produced it. The GitHub release also publishes
SHA256SUMS.txt, a Sigstore signature over that list, and build
provenance naming the workflow run, commit and tag.
The verification steps walk through all three, and they are
worth running whether or not a file is signed.
Our two official distribution channels are listed on our official domains page.