How to verify a download is genuine

Reviewed 12 September 2026 by MASTERPANEL LLC 6 min read Sources and testing: Version covered: GitHub release 1.5.0. Provenance command checked against GitHub CLI's attestation verification reference; checksum-list verification against Sigstore's Cosign documentation Editorial method

These checks establish whether a file matches the release and its recorded publisher workflow. They do not prove the program is free of malware or bugs. Hash commands are general-purpose; the signing and attestation identities below are specific to ODA. Initial tool setup may take longer than the checks themselves.

These commands apply to 1.5.0, which is published on GitHub. Run them against what you actually downloaded rather than reading them and moving on — a verification step you have never performed is not a habit, and the moment you need it is the worst moment to learn it.

First: which copy do you have?#

There are two ways to get this application, and they are verified differently. Checking the wrong thing for your copy produces a scary-looking result that means nothing, so start here.

From the Microsoft Store: Use the ODA listing linked from our download page and check its product and publisher. Windows verifies the Store package on installation and update; no manual checksum step is needed. Microsoft re-signs the MSIX/AppX package it distributes. That package signature does not mean each executable inside is individually signed.
From the GitHub release page: Use the following checks before running it. Browser or antivirus scans, if present, do not establish that it came from the intended release workflow.

Those are our two official distribution channels. A copy elsewhere might be identical, modified or unrelated; its appearance cannot tell you which. Obtain the release from the Store or the release page linked on our download page, both of which appear on the list of addresses we publish from — see what a counterfeit build does.

1. Get the checksums from the release page itself#

Every release carries a SHA256SUMS.txt listing each artifact and its hash. Take it from the release page on the source repository — not from a mirror, and not from wherever you got the installer.

2. Compute the hash of what you downloaded#

Windows (PowerShell)#

Get-FileHash -Algorithm SHA256 .\open-desktop-authenticator-1.5.0-x64-setup.exe

Linux#

sha256sum open-desktop-authenticator-1.5.0-x86_64.AppImage

macOS#

macOS ships shasum rather than sha256sum, so the Linux command above returns “command not found” on a stock Mac. There is no published macOS build of this application — this is here for someone checking a download on a Mac before moving it to the machine that will run it.

shasum -a 256 open-desktop-authenticator-1.5.0-x86_64.AppImage

Or check everything you downloaded at once, from that folder (Linux):

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

On macOS, use the single-file command above and compare its output manually; shasum options vary by the version supplied with macOS.

--ignore-missing matters. The list covers every file in the release, and you almost certainly downloaded one of them — without it, sha256sum reports FAILED open or read for absent files. That differs from a checksum mismatch. With --ignore-missing, make sure your actual download is named in the output with OK; an unrelated file or no matching files does not verify your download.

PowerShell prints its hash in upper case and the list is in lower case. That is the same value written two ways, not a mismatch — compare the characters, not the capitals.

3. Compare#

The hash you computed must match the line for that filename exactly. Not "starts with the same characters" — the whole string. If it differs by one character, the file is not the file we published. Delete it.

4. Check where the bytes came from#

A matching SHA-256 checksum establishes equality with the expected bytes. It does not prove who produced it — anyone who can replace the download can also replace the list of hashes sitting next to it. What closes that gap is a statement, made by something other than us, about which build produced these bytes.

The release workflow publishes a signed provenance statement for the executable artifacts. Its signing identity is tied to GitHub Actions. You can check it:

gh attestation verify <file> --repo opendesktopauthenticator/open-desktop-authenticator --signer-workflow opendesktopauthenticator/open-desktop-authenticator/.github/workflows/release.yml --source-ref refs/tags/vX.Y.Z --deny-self-hosted-runners

Replace <file> with the downloaded filename and vX.Y.Z with its release tag. A pass confirms that the file's digest is covered by verified provenance naming this repository, workflow and tag, with a GitHub-hosted attestation runner. It does not prove the program is safe or reproducible; it narrows the claim to the producer and source you intended to trust instead of accepting any repository or workflow under the same organisation. The command needs the GitHub CLI. If it asks you to authenticate, use gh auth login through GitHub's own flow. Network errors, missing attestations and identity mismatches are different failures: resolve the reported cause before running the file, and do not remove identity checks to make a command pass. For commit-level pinning, add --source-digest with the independently checked full commit SHA.

5. Check the checksum list is ours#

Step 1 told you to take SHA256SUMS.txt from the release page rather than from wherever you got the installer, and that advice was doing a lot of work: a hash file proves nothing about itself. Anyone who could swap a binary on a page could usually swap the list beside it. That list is now signed.

cosign verify-blob SHA256SUMS.txt   --signature SHA256SUMS.txt.sig   --certificate SHA256SUMS.txt.pem   --certificate-identity 'https://github.com/opendesktopauthenticator/open-desktop-authenticator/.github/workflows/release.yml@refs/tags/vX.Y.Z'   --certificate-oidc-issuer https://token.actions.githubusercontent.com

Replace vX.Y.Z with the version you downloaded — the identity names the exact tag, so it will not match any other release. That is deliberate. This command used to check only that the signer was somewhere under our GitHub organisation, which would have accepted a signature minted by any workflow in any repository we own, run from any branch. Checking the whole identity is the difference between “someone we know signed something” and “this release was built by this workflow from this tag”.

Both files are on the release beside the list itself. The signature is keyless — there is no long-lived release-signing private key held by this project; the certificate is minted for the workflow run that produced the release and expires minutes later. That is deliberate: a key held by one maintainer is a key that can be lost or taken, and this project has one maintainer.

It needs cosign. If you would rather not install it, the checksums and the attestation above still stand on their own — this step tells you the list came from our workflow, not just that your file matches it.

6. On Windows, check the publisher#

Get-AuthenticodeSignature .\<file>.exe | Format-List Status, SignerCertificate

What you should see depends on where the file came from, and right now the honest answer for direct downloads is uncomfortable:

A Store install: The Store package is signed and Windows checks it when installing. The command above checks a standalone .exe, not its enclosing MSIX/AppX package; an executable inside a signed package can report NotSigned without contradicting the package signature.
A download from the release page, today: Status will read NotSigned. These builds carry no code-signing certificate, and none is planned, so Windows may also warn on first run, depending on Windows policy. That is stated here rather than left for you to discover — but it does mean this step cannot tell you anything about our direct downloads, and steps 3 and 4 are doing all the work. The Store build is the one that carries a signature, and there the signer is Microsoft.

An unexpected signature or any checksum/provenance failure is a reason to stop and investigate. NotSigned alone is not a successful verification: counterfeits can be unsigned too. Use the release's stated signing status and the preceding checks together.

Going further: build it yourself#

You can inspect the source and build the tag yourself using the repository's build instructions. This changes which build environment you trust; it does not eliminate trust in source code, dependencies or your compiler.

Comparing your build's hash against ours is not yet meaningful. Getting identical bytes from the same source — a reproducible build — takes deliberate work on toolchains and timestamps that this project has not finished. Until it is done, a mismatch would tell you nothing, and we would rather say so than let you draw a false conclusion from it. The download page tracks the state of that work.