Idea: Authenticode signing for the Windows builder and launcher, separate from signed release manifests #46

New issue

Open

opened 2026-11-12 23:57:25 +00:00 by mooki · 1 comment

mooki commented

2026-11-12 23:57:25 +00:00

The idea

Give Longshot's distributed Windows programs a verified publisher identity, to reduce unknown-publisher warnings and help with antivirus false alarms. This is Windows Authenticode signing, not a replacement for the signed-release design already proposed on the forge. Signing is useful, but it cannot promise that Defender, SmartScreen or another antivirus will accept every new file.

What the forge's signing already proposes

Longshot PR 13 and LongshotLauncher PR 1 are open. They sign release metadata and channel pointers with project-controlled ECDSA P-256/SHA-256 keys:

longshot-release.json names the release's product, version and files, with sizes and SHA-256 hashes. For the builder, the signed parts list in turn names each part by its hash.
Signed stable, rc and nightly pointers identify the offered release. The launcher checks the product, channel, signature and remembered channel serial, and checks downloaded bytes against the authenticated hashes.
The nightly key may sign nightlies only; the release key signs stable and rc and may be kept offline. This authenticates release content to a launcher that already trusts those public keys and rejects older channel serials it has seen.

That does not put an Authenticode signature in a Windows EXE, establish a Windows-trusted publisher identity, attest that the build faithfully used its named source, or transfer SmartScreen reputation to it. The launcher must itself be obtained and trusted first. At the inspected heads, the built-in release-key lists are still empty; these are proposed release mechanisms, not a claim that signed Longshot releases are already shipping.

The launcher has already recognized the remaining problem: its README explicitly lists Authenticode as planned. Its packaging recipe builds the Windows EXE but does not code-sign it. The ask here is therefore to agree the identity, signing service and coverage for that planned work, including the builder/setup programs delivered by Longshot, rather than propose another manifest format.

What can be prepared

Agree the binaries and publisher. Cover the launcher EXE and the project's Windows setup/builder binaries, including the setup repackaged as LongshotBuilder.exe for RecompLauncher. Inventory third-party components separately; do not sign someone else's binaries as our own.
Complete and version the setup's resources. Current builder/setup/setup.rc has numeric FILEVERSION and PRODUCTVERSION both fixed at 1.0.0.0, a FileVersion string of 1.0.0, no ProductVersion string or copyright string, and OriginalFilename=LongshotBuilder-Setup.exe. PR 13 also distributes that setup as LongshotBuilder.exe. Tie the versions to the release and choose consistent metadata for the distributed names. The numeric product version exists; it is the string and release-specific values that are missing.
Integrate the chosen service into the Forgejo release paths. Sign and timestamp the final Windows binaries before making the package/parts hashes and signed release manifests. Signing afterwards would change the bytes the launcher verifies. Keep private keys and service credentials outside PR jobs and the repository.
Make signing-required releases fail closed. Once a product/channel is meant to be code-signed, a missing signature, wrong publisher or failed signature verification must stop its publication. Test the signed programs on Windows; successful cross-compilation is not that test.
Update the download guidance and signing policy. Explain the two signature layers, the expected publisher, how to verify a download, and how to submit an incorrect malware detection to Microsoft. Do not tell players that the project-key manifest signature is a Windows certificate or a guarantee that a program is harmless.

Options, not a decision for the maintainers

Microsoft's signing comparison currently gives these approximate costs; they are published estimates, not a quote for this team:

Route	Cost	Conditions to resolve
SignPath Foundation	Free for accepted open-source projects	The publisher is SignPath Foundation. Acceptance, verifiable automated builds, repository control and manual release approval matter; confirm the Forgejo integration and which binaries qualify.
Azure Artifact Signing	About USD 9.99/month	Identity verification; currently organizations in the USA, Canada, EU and UK, and individuals in the USA and Canada. Confirm the team's eligibility.
OV certificate	Typically USD 150–300/year	CA identity verification and a hardware token or cloud HSM for the key.
EV certificate	USD 400/year and up	No longer buys an immediate SmartScreen bypass; no reason to pay the premium solely for that.

SignPath's conditions also call for consistent product names/versions, an explicit Code signing policy naming committers/reviewers/approvers, a privacy statement, MFA, an uninstall route, and eligible open-source components. Whether Longshot and its Forgejo builds meet those conditions is for SignPath and the maintainers to settle. Hookshot's old application discussion is not confirmation of an application or approval for the new team and repositories.

Anything else

Microsoft's SmartScreen guidance distinguishes file-hash reputation from publisher reputation. A consistent trusted signing identity lets reputation accumulate across releases, but a newly signed file can still warn. Self-signed certificates do not establish public trust, and EV certificates no longer skip this process. Malware classification is a separate question; a false-positive submission is not a request to switch off SmartScreen.

The locally compiled longshot.exe is another boundary: signing the distributed builder or launcher does not sign each player's game. Smart App Control can block unsigned programs without positive reputation, including locally built ones. The docs should explain that limit separately, not promise that signing the launcher fixes it or recommend disabling security as a general remedy.

Nothing here was tested on Windows or against an antivirus. The old Hookshot executable's size, hash, unsigned status and release/issue counts are not measurements of Longshot and are not being carried over as current evidence.

Two questions:

Has SignPath answered the earlier application, and would it cover Longshot's new maintainers and Forgejo repositories, or is a new application/service decision needed?
Would you like the metadata, release integration, verification and policy preparation now, coordinated with the launcher's already planned Authenticode work, or only after the signing route is chosen?

Who signs remains the maintainers' decision: it carries a legal identity, costs money or approval time, and can be revoked. I can offer the repository-side preparation once that scope is agreed.

Moved from NotRexed/Hookshot#2919.

### The idea Give Longshot's distributed Windows programs a verified publisher identity, to reduce unknown-publisher warnings and help with antivirus false alarms. This is **Windows Authenticode signing**, not a replacement for the signed-release design already proposed on the forge. Signing is useful, but it cannot promise that Defender, SmartScreen or another antivirus will accept every new file. #### What the forge's signing already proposes [Longshot PR 13](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/13) and [LongshotLauncher PR 1](https://git.magicbean.dev/MagicBeanDev/LongshotLauncher/pulls/1) are open. They sign **release metadata and channel pointers** with project-controlled ECDSA P-256/SHA-256 keys: - `longshot-release.json` names the release's product, version and files, with sizes and SHA-256 hashes. For the builder, the signed parts list in turn names each part by its hash. - Signed `stable`, `rc` and `nightly` pointers identify the offered release. The launcher checks the product, channel, signature and remembered channel serial, and checks downloaded bytes against the authenticated hashes. - The nightly key may sign nightlies only; the release key signs stable and rc and may be kept offline. This authenticates release content to a launcher that already trusts those public keys and rejects older channel serials it has seen. That does **not** put an Authenticode signature in a Windows EXE, establish a Windows-trusted publisher identity, attest that the build faithfully used its named source, or transfer SmartScreen reputation to it. The launcher must itself be obtained and trusted first. At the inspected heads, the built-in release-key lists are still empty; these are proposed release mechanisms, not a claim that signed Longshot releases are already shipping. The launcher has already recognized the remaining problem: its [README](https://git.magicbean.dev/MagicBeanDev/LongshotLauncher/src/commit/1bac9380122026887d123300a921e1508ba2c461/README.md#planned-next) explicitly lists **Authenticode** as planned. Its packaging recipe builds the Windows EXE but does not code-sign it. The ask here is therefore to agree the identity, signing service and coverage for that planned work, including the builder/setup programs delivered by Longshot, rather than propose another manifest format. #### What can be prepared 1. **Agree the binaries and publisher.** Cover the launcher EXE and the project's Windows setup/builder binaries, including the setup repackaged as `LongshotBuilder.exe` for RecompLauncher. Inventory third-party components separately; do not sign someone else's binaries as our own. 2. **Complete and version the setup's resources.** Current `builder/setup/setup.rc` has numeric `FILEVERSION` and `PRODUCTVERSION` both fixed at `1.0.0.0`, a `FileVersion` string of `1.0.0`, no `ProductVersion` string or copyright string, and `OriginalFilename=LongshotBuilder-Setup.exe`. PR 13 also distributes that setup as `LongshotBuilder.exe`. Tie the versions to the release and choose consistent metadata for the distributed names. The numeric product version exists; it is the string and release-specific values that are missing. 3. **Integrate the chosen service into the Forgejo release paths.** Sign and timestamp the final Windows binaries **before** making the package/parts hashes and signed release manifests. Signing afterwards would change the bytes the launcher verifies. Keep private keys and service credentials outside PR jobs and the repository. 4. **Make signing-required releases fail closed.** Once a product/channel is meant to be code-signed, a missing signature, wrong publisher or failed signature verification must stop its publication. Test the signed programs on Windows; successful cross-compilation is not that test. 5. **Update the download guidance and signing policy.** Explain the two signature layers, the expected publisher, how to verify a download, and how to submit an incorrect malware detection to [Microsoft](https://www.microsoft.com/en-us/wdsi/filesubmission). Do not tell players that the project-key manifest signature is a Windows certificate or a guarantee that a program is harmless. #### Options, not a decision for the maintainers [Microsoft's signing comparison](https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/code-signing-options) currently gives these approximate costs; they are published estimates, not a quote for this team: | Route | Cost | Conditions to resolve | |---|---|---| | [SignPath Foundation](https://signpath.org/terms.html) | Free for accepted open-source projects | The publisher is SignPath Foundation. Acceptance, verifiable automated builds, repository control and manual release approval matter; confirm the Forgejo integration and which binaries qualify. | | Azure Artifact Signing | About USD 9.99/month | Identity verification; currently organizations in the USA, Canada, EU and UK, and individuals in the USA and Canada. Confirm the team's eligibility. | | OV certificate | Typically USD 150–300/year | CA identity verification and a hardware token or cloud HSM for the key. | | EV certificate | USD 400/year and up | No longer buys an immediate SmartScreen bypass; no reason to pay the premium solely for that. | SignPath's conditions also call for consistent product names/versions, an explicit **Code signing policy** naming committers/reviewers/approvers, a privacy statement, MFA, an uninstall route, and eligible open-source components. Whether Longshot and its Forgejo builds meet those conditions is for SignPath and the maintainers to settle. Hookshot's [old application discussion](https://github.com/NotRexed/Hookshot/issues/525) is not confirmation of an application or approval for the new team and repositories. ### Anything else [Microsoft's SmartScreen guidance](https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/smartscreen-reputation) distinguishes file-hash reputation from publisher reputation. A consistent trusted signing identity lets reputation accumulate across releases, but a newly signed file can still warn. Self-signed certificates do not establish public trust, and EV certificates no longer skip this process. Malware classification is a separate question; a false-positive submission is not a request to switch off SmartScreen. The locally compiled `longshot.exe` is another boundary: signing the distributed builder or launcher does not sign each player's game. Smart App Control can block unsigned programs without positive reputation, including locally built ones. The docs should explain that limit separately, not promise that signing the launcher fixes it or recommend disabling security as a general remedy. Nothing here was tested on Windows or against an antivirus. The old Hookshot executable's size, hash, unsigned status and release/issue counts are not measurements of Longshot and are not being carried over as current evidence. Two questions: 1. Has SignPath answered the earlier application, and would it cover Longshot's new maintainers and Forgejo repositories, or is a new application/service decision needed? 2. Would you like the metadata, release integration, verification and policy preparation now, coordinated with the launcher's already planned Authenticode work, or only after the signing route is chosen? Who signs remains the maintainers' decision: it carries a legal identity, costs money or approval time, and can be revoked. I can offer the repository-side preparation once that scope is agreed. --- Moved from NotRexed/Hookshot#2919.

mooki referenced this issue

2026-11-13 02:39:37 +00:00

WIP: ci(windows): optionally sign builder executables with Authenticode #98

mooki commented

2026-11-13 02:39:38 +00:00

Author

The release rework is now merged in Longshot #13 and LongshotLauncher #1. It uses one P-256 key over SHA256SUMS, not the earlier manifest/channel-pointer design. The public key is present. That authenticates release downloads to the launcher; it does not give a Windows EXE a verified publisher.

The repository-side first slice is pull request 98 (work in progress): optional signing of the compiled setup and the WPF builder apphost before packaging, followed by verification of Windows trust, the selected certificate and a timestamp. The setup's top-level LongshotBuilder.exe and Repair copy retain the same signed bytes. No third-party tools are re-signed. With no certificate configured, the log says not signed: no certificate configured and the build remains unsigned. PRs never enter the signing step.

The decisions that remain with maintainers are:

Buy/apply now, or stay explicitly unsigned? The optional step changes no default. Once a channel promises signed Windows files, missing configuration must also stop publication; which channels should carry that promise?

Which identity and service? These are estimates, not quotes:

Option	Estimated cost	What needs deciding
Ordinary OV certificate	USD 150–300/year	the legal publisher, CA and token/HSM or cloud arrangement; hardware/service charges may be extra
EV certificate	USD 400/year and up	whether stricter identity validation is useful; it no longer buys a SmartScreen bypass
Azure Artifact Signing	about USD 9.99/month	eligibility, project account and service-specific integration
SignPath Foundation	free if accepted	a Longshot/Forgejo application and verifiable-build/manual-approval requirements; the publisher would be SignPath Foundation
Stay unsigned for now	no certificate charge	retain explicit unknown-publisher/trust limits rather than claiming manifest signing solves them

Sources: Microsoft's comparison, current Artifact Signing prerequisites, and SignPath's conditions. Microsoft's comparison and service quickstart currently disagree on the list of eligible organization regions, so eligibility should be checked directly. No SignPath acceptance for Longshot is assumed.

Who holds and approves it? Please choose the legal certificate/account holder, a backup custodian, release approvers, budget owner and renewal/revocation contact. Both OV and EV now need suitable protected keys; the CA/Browser Forum rules permit approved hardware or qualifying cloud/signing services, not an ordinary exportable-key procurement plan. The prepared route selects a certificate already available through Windows' certificate store; it does not export a private key or implement Azure/SignPath APIs. A signing runner and its provider must deny PR workloads independently of workflow labels. Do not provision an identity on a general PR runner.
Coverage and metadata policy. The launcher is built in its own repository, from one Windows program copied into setup and portable forms; it still needs its own signing integration. The setup's fixed 1.0.0 resources and missing ProductVersion/copyright strings need release-specific values and an agreed publisher. Which publisher should both products display?

Evidence so far: 12 signing decision/command/failure tests pass. An actual Linux stand-in signed a 1,536-byte authored PE with a temporary self-signed certificate (3,472 bytes after signing), verified its embedded signature and all three package paths with that certificate explicitly trusted for the test, and rejected a modified code section. It also checked the final zip's release checksum. The temporary keys were removed; no trust store was changed. This proves mechanics, not publisher trust. Windows PowerShell, a hardware/cloud provider, the timestamp server, SmartScreen/Defender behaviour and a real release workflow have not been exercised.

Microsoft's SmartScreen guidance still warns that new signed files can prompt. Signing these distributed tools also does not sign a player's locally compiled game. None of this recommends disabling security protection.

The release rework is now merged in [Longshot #13](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/13) and [LongshotLauncher #1](https://git.magicbean.dev/MagicBeanDev/LongshotLauncher/pulls/1). It uses one P-256 key over `SHA256SUMS`, not the earlier manifest/channel-pointer design. The public key is present. That authenticates release downloads to the launcher; it does not give a Windows EXE a verified publisher. The repository-side first slice is [pull request 98](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/98) (work in progress): optional signing of the compiled setup and the WPF builder apphost before packaging, followed by verification of Windows trust, the selected certificate and a timestamp. The setup's top-level `LongshotBuilder.exe` and Repair copy retain the same signed bytes. No third-party tools are re-signed. With no certificate configured, the log says `not signed: no certificate configured` and the build remains unsigned. PRs never enter the signing step. The decisions that remain with maintainers are: 1. **Buy/apply now, or stay explicitly unsigned?** The optional step changes no default. Once a channel promises signed Windows files, missing configuration must also stop publication; which channels should carry that promise? 2. **Which identity and service?** These are estimates, not quotes: | Option | Estimated cost | What needs deciding | |---|---|---| | Ordinary OV certificate | USD 150–300/year | the legal publisher, CA and token/HSM or cloud arrangement; hardware/service charges may be extra | | EV certificate | USD 400/year and up | whether stricter identity validation is useful; it no longer buys a SmartScreen bypass | | Azure Artifact Signing | about USD 9.99/month | eligibility, project account and service-specific integration | | SignPath Foundation | free if accepted | a Longshot/Forgejo application and verifiable-build/manual-approval requirements; the publisher would be SignPath Foundation | | Stay unsigned for now | no certificate charge | retain explicit unknown-publisher/trust limits rather than claiming manifest signing solves them | Sources: [Microsoft's comparison](https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/code-signing-options), [current Artifact Signing prerequisites](https://learn.microsoft.com/en-us/azure/artifact-signing/quickstart#prerequisites), and [SignPath's conditions](https://signpath.org/terms.html). Microsoft's comparison and service quickstart currently disagree on the list of eligible organization regions, so eligibility should be checked directly. No SignPath acceptance for Longshot is assumed. 3. **Who holds and approves it?** Please choose the legal certificate/account holder, a backup custodian, release approvers, budget owner and renewal/revocation contact. Both OV and EV now need suitable protected keys; [the CA/Browser Forum rules](https://cabforum.org/working-groups/code-signing/requirements/) permit approved hardware or qualifying cloud/signing services, not an ordinary exportable-key procurement plan. The prepared route selects a certificate already available through Windows' certificate store; it does not export a private key or implement Azure/SignPath APIs. A signing runner and its provider must deny PR workloads independently of workflow labels. Do not provision an identity on a general PR runner. 4. **Coverage and metadata policy.** The launcher is built in its own repository, from one Windows program copied into setup and portable forms; it still needs its own signing integration. The setup's fixed `1.0.0` resources and missing `ProductVersion`/copyright strings need release-specific values and an agreed publisher. Which publisher should both products display? Evidence so far: 12 signing decision/command/failure tests pass. An actual **Linux stand-in** signed a 1,536-byte authored PE with a temporary self-signed certificate (3,472 bytes after signing), verified its embedded signature and all three package paths with that certificate explicitly trusted for the test, and rejected a modified code section. It also checked the final zip's release checksum. The temporary keys were removed; no trust store was changed. This proves mechanics, **not publisher trust**. Windows PowerShell, a hardware/cloud provider, the timestamp server, SmartScreen/Defender behaviour and a real release workflow have not been exercised. [Microsoft's SmartScreen guidance](https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/smartscreen-reputation) still warns that new signed files can prompt. Signing these distributed tools also does not sign a player's locally compiled game. None of this recommends disabling security protection.