Windows release evidence: hashes, provenance, and signing

Scope

This draft separates file hashes, build provenance, Authenticode, and user-facing reputation signals for a Python GUI app on Windows 11 x64. It does not supply a malware classification, certificate, signing service, Store decision, or SmartScreen outcome.

The estate’s --onedir status is a separate licensing and distribution decision: for PolyForm Noncommercial/Internal Use builds, bundled LGPL Qt and other LGPL libraries must remain replaceable by end users. It is not evidence that --onedir is generally better.

Answer

Use each mechanism for its own claim.

Mechanism	What it can show	What it does not show
SHA-256 hash	Downloaded bytes match a published value when compared correctly.	Who built the file, whether it is benign, or whether Windows will trust it.
Build provenance attestation	A verified artifact was built by the named workflow from the named public source.	Malware safety, a commercial identity, or SmartScreen reputation.
Authenticode signature	A Windows signature can identify a signer and detect post-signing integrity changes, subject to Windows trust evaluation.	Malware safety or a fixed SmartScreen result.
SmartScreen and similar reputation signals	Windows may use them in download and execution decisions.	A result established by a hash, provenance, or certificate alone.

Decision path

Publish a SHA-256 file for each artifact when you want users to compare bytes.
Attach build provenance when your release system supports it, and document the source and workflow verification command.
Use Authenticode only when you have a signing identity and operation that you can validate. Do not describe an unsigned artifact as signed.
Treat SmartScreen results and external Store or WinGet acceptance as outcomes outside these mechanisms.

Production evidence

The Build-Tools release workflow calculates SHA-256 files for the ZIP and installer and submits both files to GitHub’s provenance attestation action. The Build-Tools README gives the gh attestation verify shape and required signer repository. The shared installer script retains a commented signing hook rather than establishing signed production artifacts.

For WinGet, Simple UNA Log Viewer’s initial submission and update document that application’s accepted lifecycle only. They do not change the distinct meanings of hashes, provenance, or Authenticode.

Unsupported or external outcomes

Authenticode-signed estate artifacts are not reproduced.
No mechanism here proves malware safety.
No mechanism here proves or controls SmartScreen reputation.
Microsoft Store or MSIX is external. Store distribution may be viable but is not reproduced here.
General WinGet acceptance is external; Simple UNA Log Viewer is the limited accepted lifecycle example.
--onefile and standalone native PySide6 output are not reproduced for the mapped PolyForm route. This does not say --onefile universally violates LGPL; other license and distribution models need their own analysis and testing.
This is not legal advice. Layout alone does not fulfill all license obligations; notices, source or offer requirements, and the actual dependency and license versions still matter.

Source ledger