Code signing policy

Borea releases are not code signed yet. Windows and macOS therefore warn on the first start of each version, and the README explains the extra step.

This page describes how releases are produced today and the rules signing will follow once a certificate is in place.

Windows releases will be signed through the open source program of the SignPath Foundation. A signed build then names SignPath Foundation as its publisher, not an individual. Windows can still warn about the first signed versions, because its reputation for a new certificate grows with the number of people who download a build.

• Every published file is built by the release workflow in GitHub Actions, from a tag on main in KSAModding/Borea. Nothing is built on a maintainer's computer.
• The test suites run first and a failure stops the release.
• Each release carries a CycloneDX SBOM, build provenance attestations, and a SHA256SUMS.txt whose contents are also printed in the release notes.
• The workflow is part of the repository, so any change to how releases are built goes through a pull request like any other change.

• The Windows programs in the archives of a stable release.
• Pre-releases, meaning any tag with a hyphen such as v0.5.0-beta.1, stay unsigned. They are test builds for developers.
• macOS builds are ad-hoc signed by the SDK during the build and are not notarised.
• Signing happens inside the release workflow, after the tests and before publishing. A release that cannot be signed is either not published or published unsigned and said so in its notes, never published as if it had been signed.
• No private key exists on any maintainer's computer. The release workflow requests the signature and the signing service performs it.

The KSAModding organisation requires two factor authentication for every member.

• Authors may change the source and merge their own work: @averageksp, @Maximilian-Nesslauer, @MrJeranimo.
• Reviewers review every contribution from someone who is not an author, before it is merged: the authors above, and @PlazmaBoltz and @renancamm, who also have write access.
• Approvers decide that a given release may be signed, and every signing request needs the manual approval of one of them: the three authors above.

A release starts when an approver pushes a version tag. The signing request itself always comes from the release workflow and never from a person.

The same rules for contributors are in CONTRIBUTING.md.

Compare the checksum of the file you downloaded with the table in the release notes, or with SHA256SUMS.txt from the same release.

# Windows, PowerShell
Get-FileHash .\Borea-0.4.0-win-x64.zip -Algorithm SHA256

# Linux and macOS
shasum -a 256 Borea-0.4.0-linux-x64.tar.gz

Build provenance ties each file to the workflow run that produced it, and the GitHub CLI checks it:

gh attestation verify Borea-0.4.0-win-x64.zip --repo KSAModding/Borea \
  --signer-workflow KSAModding/Borea/.github/workflows/release.yml

Without --signer-workflow, an attestation from any workflow of the repository would pass.

Borea is only released here. A Borea build offered anywhere else is not ours, whatever it is signed with.

Borea is a desktop program that keeps its data on your computer. It has no account of its own, it sends no usage data, and what it fetches by itself is listed in the privacy statement.

If a file claims to be Borea and its checksum does not match, or a signed build behaves in a way a mod manager should not, report it through the private path in SECURITY.md. Please do not open a public issue for it.