Code signing & verifying your download¶

This page describes how YazSes release binaries are produced, signed and verified, so that you can check a download is genuine before you run it.

Why this matters¶

An installer you download from the internet can be tampered with between the project's build server and your machine. Two independent mechanisms protect against that:

• A checksum proves the file you have is byte-for-byte the file the project published — provided you get the checksum from a trustworthy place.
• A code signature proves the file was produced by the project and has not been modified since, and is what stops your operating system from warning you.

Verify a download with checksums¶

Every release publishes a SHA256SUMS.txt asset listing the hash of each artifact, generated by the release workflow directly from the uploaded files.

Get-FileHash .\YazSes-<version>-windows-x64.exe -Algorithm SHA256

sha256sum --check --ignore-missing SHA256SUMS.txt

Compare the result against the matching line in SHA256SUMS.txt on the releases page. If they differ, do not run the file — please open an issue.

Verify build provenance (works even while binaries are unsigned)¶

Every release artifact — the .deb, the .dmg, the .exe and the PyPI wheel — carries a build provenance attestation: a signed statement that this exact file was produced by this workflow, from this commit, in this repository. It is generated by GitHub's OIDC identity during the release run, so there is no private key for anyone to leak or steal.

gh attestation verify yazses_2.43.2_amd64.deb --repo MSKazemi/yazses

From v2.45.0, the MCP bundle (yazses-<version>.mcpb, see Connect YazSes to an MCP client) is attested too, and its bundle is attached as yazses-<version>-mcpb.intoto.jsonl.

A pass tells you the file came out of this repository's CI and has not been altered since. That is a different guarantee from a code signature, and for now a stronger one here: the binaries are not yet code-signed, so provenance is the only cryptographic link between a download and this source tree.

For the PyPI wheel, attestations are PEP 740 and are attached by the same trusted-publishing identity that uploads it. PyPI publishes them next to the wheel and the source archive, and you can verify one with PyPI's pypi-attestations tool:

pypi-attestations verify pypi --repository https://github.com/MSKazemi/yazses \
    pypi:yazses-<version>-py3-none-any.whl

Since 2026-08-14. Every release cut after that date carries attestations. Each release also attaches the bundles as *.intoto.jsonl assets, so you can verify without querying GitHub, for example gh attestation verify yazses_2.43.2_amd64.deb --bundle yazses-2.43.2-deb.intoto.jsonl --repo MSKazemi/yazses. If verification fails on an artifact older than that date, the artifact predates the change rather than being tampered with — check the release date before assuming the worst.

Verify a code signature¶

Once signing is active, Windows releases are Authenticode-signed.

Right-click the .exe → Properties → Digital Signatures, or in PowerShell:

Get-AuthenticodeSignature .\YazSes-<version>-windows-x64.exe | Format-List

You want Status: Valid and a signer certificate issued to SignPath Foundation.

Code signing policy¶

This is the policy the project commits to for every signed release.

Team roles.

Committers are the people trusted to modify the source in this repository. Every change proposed by someone who is not a committer, such as a pull request from a fork, is reviewed by a committer before it is merged. Every team member is required to use multi-factor authentication on both GitHub and SignPath.

Privacy. See the privacy statement. YazSes sends nothing you say anywhere by default. Every network connection it can make, and the third-party services involved (model downloads from Hugging Face, package installs from PyPI, update checks against GitHub Releases), is listed with its trigger in the egress inventory.

What gets signed. Only artifacts built by the project's own GitHub Actions workflow (build-windows.yml) from a tag on the public repository. Nothing built on a developer machine is ever submitted for signing.

Who approves. Every signing request requires manual approval by the project maintainer. Signing is not automatic on push.

Key custody. Signing keys are held in SignPath's HSM. No maintainer, no contributor and no CI job ever has access to private key material — the build uploads an unsigned artifact and receives a signed one back.

Reproducibility. Releases are cut only from tags on the public repository, so every signed binary corresponds to a commit that anyone can inspect, and the build logs are public.

Reporting a problem. If you encounter a YazSes binary whose signature does not validate, or which your antivirus flags, please report it via GitHub Security Advisories or by opening an issue.

Why your antivirus may still complain¶

YazSes does two things that heuristic scanners associate with keyloggers, because they are genuinely the same OS facilities:

• It installs a global keyboard hook so it can detect the press and release of your hold-to-talk key while another application has focus. It watches one configured key and never records, stores or transmits what you type.
• It injects keystrokes into the focused window — this is how transcribed text is delivered, and it is the entire output mechanism of any dictation tool.

Commercial dictation software (Dragon NaturallySpeaking, Talon Voice, Windows Voice Access) uses the same two mechanisms. YazSes sends nothing you say anywhere by default. Every connection it can make (model and package downloads, update checks and installs, and the two opt-in features that can forward dictated text) is listed with its trigger in the egress inventory; see the privacy statement and ADR-011, which makes "nothing leaves the machine" a binding architectural constraint.

SmartScreen¶

A newly signed application still shows a SmartScreen warning until it accumulates download reputation — this happens to every new publisher and is not specific to YazSes. Click More info → Run anyway. The warning shown for a signed application is milder than the hard block shown for unsigned ones, and it fades as downloads accumulate.

See also: Install on Windows · Privacy statement