Support changes take effect when the signed and notarized release is published, not when its version is prepared in the repository. Fixes land on the active development branch and ship in the current supported minor or the next minor release. Older builds aren't patched separately. Check the download page for the current published version.

Email security@codeswhat.com with “Mouthtype security” in the subject, or use GitHub's private vulnerability reporting. Don't put vulnerabilities, personal audio, transcripts, credentials or permission databases in public issues, discussions or pull requests.

Include the affected version or source revision, macOS version, reproduction steps, impact and a minimal synthetic example. Send sensitive evidence only after agreeing on a suitable transfer method. You can expect an acknowledgement within 7 days and a status update after triage. Fix timing depends on severity and maintainer availability, and no fix deadline is guaranteed. Reporters are credited in the release notes unless they prefer to stay anonymous.

Relevant reports include unintended disclosure of recordings or text, delivery into an unintended destination, unsafe handling of imported files or downloaded models, compromised update verification, and build or release credential exposure. Mouthtype is a single-user local application with broad macOS Accessibility access. A person already controlling the user's account can read its local data and operate the same permissions; it isn't a sandbox or a defense against a compromised Mac.

See security controls and limits for implemented safeguards, evidence and remaining gaps. To check a download's signature and build provenance, see Verify a download. A security score or notarization alone doesn't establish that an app is safe.

The release source inventory records exact resolved Swift source revisions and verified artifact hashes within its stated scope. It does not establish complete binary composition. No SLSA level or independent third-party security audit is claimed.