Is my PhotoCraft download official? Check the SHA256 and signatures
Make sure a PhotoCraft download is the official, unmodified build: SHA256SUMS.txt on every platform, the Windows code signature, the macOS Developer ID and notarization, and the Linux GPG signatures.
You can check for yourself that a PhotoCraft download is the official build and hasn't been changed. Every release on the storytold/photocraft GitHub releases page has a SHA256SUMS.txt with one checksum per file, so on any platform you can confirm a file is byte for byte the one the project published. On top of that, the Windows MSI and programs carry an Authenticode code signature, the macOS app and DMG are signed with a Developer ID and notarized by Apple, and since v0.20.2 the Linux files and SHA256SUMS.txt are signed with a GPG key. This page shows how to run each check, as of v0.23.1 (12 November 2026).
These checks tell you where a file came from and that it is intact. They don't make any software bug-free. PhotoCraft is open source (MIT OR Apache-2.0), and its release builds run in the project's public GitHub Actions workflow, so the logs of each release build are public too (the v0.23.1 run).
At a glance
| Download | Checksum in SHA256SUMS.txt | Signature | Quickest check |
|---|---|---|---|
Windows .msi | Yes | Authenticode, signed by Learning Machines Inc | File Properties › Digital Signatures |
Windows portable .zip | Yes | The zip itself isn't signed; photocraft.exe and photocraft-cli.exe inside are | Checksum, then the exe's signature |
macOS .dmg and photocraft-cli zip | Yes | Developer ID Application: Learning Machines LLC (DJ6XS33FX8), notarized | spctl -a -vv on the installed app |
Linux AppImage, .deb, .rpm, Flatpak, tarball, Arch package | Yes | GPG, since v0.20.2 | gpg --verify |
| FreeBSD tarball | Yes | None of its own | Checksum, with SHA256SUMS.txt.asc |
Web build .zip | Yes | None of its own | Checksum, with SHA256SUMS.txt.asc |
Where official builds come from
Official PhotoCraft builds are published only as release files on github.com/storytold/photocraft/releases. The project's PhotoCraft page on getartcraft.com, which the README recommends to newcomers, links to the same releases. photocraft.im is an unofficial community guide: every download link on this site, from the download page down, goes to those GitHub releases, and the site hosts no installers of its own.
Repackaged builds, such as the "Chinese edition" installers in the third-party GitHub repository awpde/photocraft-zh, are not published by the PhotoCraft project. That says nothing bad about whoever made them. It only means their files aren't in the official SHA256SUMS.txt and none of the checks below can tie them to the PhotoCraft team. You don't need them anyway: every official build already includes Simplified and Traditional Chinese, as Language settings explains.
Check the SHA-256 on any platform
Download SHA256SUMS.txt from the same release into the folder that holds your download. Each line is a checksum and a file name. It covers every other file on the release page, including the signature files and the signing key; only SHA256SUMS.txt.asc isn't listed.
Windows (PowerShell). Compute the hash and compare it with the file's line:
Get-FileHash .\photocraft-0.23.1-windows-x64.msi -Algorithm SHA256
Select-String -Path .\SHA256SUMS.txt -SimpleMatch "photocraft-0.23.1-windows-x64.msi"
Or let PowerShell compare them. True means the file is intact:
$file = "photocraft-0.23.1-windows-x64.msi"
$expected = (Select-String -Path .\SHA256SUMS.txt -SimpleMatch $file).Line.Split(' ')[0]
(Get-FileHash $file -Algorithm SHA256).Hash -eq $expected
macOS (Terminal). shasum checks the DMG's line for you:
grep macos-universal.dmg SHA256SUMS.txt | shasum -a 256 -c
# photocraft-0.23.1-macos-universal.dmg: OK
Linux. sha256sum checks every listed file that is in the folder and skips the rest:
sha256sum -c --ignore-missing SHA256SUMS.txt
FreeBSD. Print the hash with the base system's sha256 and compare it with the file's line:
sha256 -q photocraft-0.23.1-freebsd-x86_64.tar.gz
grep freebsd-x86_64.tar.gz SHA256SUMS.txt
GitHub's own checksum. GitHub also records a SHA-256 for each release file itself and shows it on the release page next to the file. The API returns it as "digest": "sha256:…". With the GitHub CLI:
gh api repos/storytold/photocraft/releases/tags/v0.23.1 --jq '.assets[] | [.name, .digest] | @tsv'
For v0.23.1 we compared them on 12 November 2026, and the two agree for all 50 files in the list. For example, both give 3a498eb517bca6cec89f9c6b1fc6448269a05428c8a3a4637c16817da157f03c for photocraft-web-0.23.1.zip.
A matching checksum proves the file is the one on the release page. It doesn't prove who put it there, because the checksum list comes from the same page. The signatures below cover that.
Per-platform walkthroughs, with the file names for each architecture, are on the Windows, macOS and Linux download pages.
Windows: check the code signature
The release workflow signs photocraft.exe and photocraft-cli.exe, then the MSI, with signtool (SHA-256, with a timestamp) through packaging/windows/sign.ps1. The v0.23.1 x64 and arm64 builds were signed through Microsoft's Trusted Signing service, and the release log shows the certificate issued to Learning Machines Inc for both programs and the MSI of each. Since v0.22.0 there is no 32-bit x86 build to sign (craft-common-actions#163); v0.21.0, the last one, was signed the same way. The portable zip isn't signed as a file, since a zip can't carry an Authenticode signature, but the two programs inside it are. The -symbols.zip debugging files aren't signed either.
In Explorer. Right-click the MSI (or photocraft.exe from the portable zip) and choose Properties. On the Digital Signatures tab, the signer should be Learning Machines Inc. Select it and click Details: Windows should say "This digital signature is OK." If the tab is missing, the file isn't signed.
In PowerShell:
$sig = Get-AuthenticodeSignature .\photocraft-0.23.1-windows-x64.msi
$sig.Status
$sig.SignerCertificate.Subject
Status must be Valid, and Subject must start with CN=Learning Machines Inc. Check both. Valid alone only means some trusted certificate signed the file, which would be true of a file signed by anyone else too. Go by the signer's name, not the certificate's thumbprint or issuing CA, which can change from one release to the next. If you install for everyone and Windows asks for administrator permission, the prompt shows the same name as the verified publisher.
Microsoft Defender SmartScreen may still warn about a correctly signed PhotoCraft download (#8338). See SmartScreen warning in Troubleshooting.
macOS: check the Developer ID and notarization
PhotoCraft.app is signed with the hardened runtime and a secure timestamp, notarized by Apple, and the notarization ticket is stapled to it. The DMG is signed, notarized and stapled as well. The signing identity in the v0.23.1 docs is Developer ID Application: Learning Machines LLC (DJ6XS33FX8), and the v0.23.1 release log shows the app, the DMG and the CLI accepted as Notarized Developer ID from Learning Machines LLC. DJ6XS33FX8 is the Team ID, which the in-app updater also expects (see below).
After you drag the app to Applications, run these in Terminal:
codesign --verify --deep --strict --verbose=2 /Applications/PhotoCraft.app
spctl -a -vv /Applications/PhotoCraft.app
xcrun stapler validate /Applications/PhotoCraft.app
codesignshould end withvalid on diskandsatisfies its Designated Requirement. That shows no file in the bundle has changed since it was signed.spctlshould printaccepted,source=Notarized Developer IDandorigin=Developer ID Application: Learning Machines LLC (DJ6XS33FX8). This is the check Gatekeeper makes when you open the app.xcrun stapler validateshould printThe validate action worked!, meaning the ticket is stapled and the app passes even offline.xcrunneeds Apple's Command Line Tools, and macOS offers to install them the first time you run it.
To see the Team ID by itself, run codesign -dv --verbose=2 /Applications/PhotoCraft.app and look for TeamIdentifier=DJ6XS33FX8. To make codesign fail outright for any other signer, which is the check the updater runs, use:
codesign --verify --deep -R '=anchor apple generic and certificate leaf[subject.OU] = "DJ6XS33FX8"' /Applications/PhotoCraft.app
You can check the DMG before you open it, too:
spctl -a -t open --context context:primary-signature -vv photocraft-0.23.1-macos-universal.dmg
xcrun stapler validate photocraft-0.23.1-macos-universal.dmg
The separate photocraft-cli-0.23.1-macos-universal.zip holds a bare binary, which can't carry a stapled ticket. Check it with spctl --assess --type install -vv, as the macOS download page shows. A Homebrew install is the same official DMG, so the commands above work on it unchanged.
Linux: check the GPG signature (since v0.20.2)
Since v0.20.2 (5 November 2026), the release workflow signs the Linux files with an OpenPGP key before it computes SHA256SUMS.txt, and then signs SHA256SUMS.txt itself. The public key is the release file release-signing-key.asc:
| Key | Value |
|---|---|
| Name | ArtCraft Linux Release Signing Key (ed25519, created 3 November 2026) |
| Primary key fingerprint | 2B76 741B 414A AD6C D33E 6312 13A0 05C0 B9D7 C3ED |
| Signing subkey | 568D C1F6 8F8F AECC 797F 3C7B 006D AF6B B0EF 334E |
What carries a signature, on every architecture the release has:
| File | Signature |
|---|---|
.AppImage, .AppImage.zsync | <file>.asc |
.deb | <file>.asc, and an embedded _gpgorigin signature (debsigs) |
.rpm | <file>.asc, and an embedded RPM signature |
.flatpak | <file>.asc |
-linux-*.tar.gz | <file>.asc |
.pkg.tar.zst (Arch) | <file>.sig, a binary signature where pacman looks for it |
SHA256SUMS.txt | SHA256SUMS.txt.asc |
| FreeBSD tarballs, Windows, macOS and web files | None; covered by SHA256SUMS.txt.asc |
Download release-signing-key.asc, SHA256SUMS.txt, SHA256SUMS.txt.asc and the signature for your file from the same release, then run:
gpg --import release-signing-key.asc
gpg --verify SHA256SUMS.txt.asc SHA256SUMS.txt
gpg --verify photocraft-0.23.1-linux-x86_64.AppImage.asc photocraft-0.23.1-linux-x86_64.AppImage
The same gpg --verify works for an Arch package's .sig. Each check should report Good signature from "ArtCraft Linux Release Signing Key", then Primary key fingerprint: 2B76 741B 414A AD6C D33E 6312 13A0 05C0 B9D7 C3ED. Compare that line with the table. We checked on 12 November 2026 with gpg 2.4 in Git Bash on Windows: the v0.23.1 SHA256SUMS.txt.asc gives a good signature from that key, made by the signing subkey above, as the v0.21.0 one did on 9 November.
gpg also prints WARNING: This key is not certified with a trusted signature!. That is expected. It only means you haven't marked the key as trusted in your own keyring. The fingerprint comparison is what replaces that step.
A good signature on SHA256SUMS.txt, followed by the sha256sum -c check above, covers every file the list names. That is how you verify the files that have no signature of their own.
For an .rpm, rpm can check the embedded signature once the key is in its keyring. The import adds the key to the RPM keys your system trusts:
sudo rpm --import release-signing-key.asc
rpm -K photocraft-0.23.1-linux-x86_64.rpm
Keep in mind:
- The key comes from the same page as the files. Someone who could replace the files could replace the key too, so a signature proves more than the checksum only when you check the fingerprint against a copy from somewhere else. As of v0.23.1 upstream's README and docs don't publish the fingerprint or mention the signatures. The fingerprint above is the one in the key files of v0.20.2, v0.21.0 and v0.23.1, which we compared; the v0.23.1 file is byte for byte the v0.21.0 one.
- Releases up to v0.20.1 aren't signed. They have only
SHA256SUMS.txt. - The in-app updater doesn't check these signatures. On Linux it relies on the SHA-256 check (see below).
.oci-manifest.jsonand.oci.sigbelong to the Flatpak build packaged as an OCI image. The manifest describes the image, and.oci.sigis a container-image signature of it forghcr.io/storytold/photocraft, the kind Flatpak checks when it installs from an OCI remote. You don't need either to install the files on the release page.
The Linux download page has the same steps next to the install instructions.
FreeBSD
The FreeBSD tarballs have no signature of their own. FreeBSD has no code-signing scheme for loose binaries, and the FreeBSD job doesn't sign anything. Check the tarball against SHA256SUMS.txt with sha256 as shown above, and check SHA256SUMS.txt with gpg --verify SHA256SUMS.txt.asc SHA256SUMS.txt (install GnuPG with pkg install gnupg). For v0.20.1 and earlier only the checksum is available. PhotoCraft can't update itself on FreeBSD.
What the in-app updater checks
Help › Check for Updates… and the update prompt use the shared craft-update library, at the revision pinned in v0.23.1's Cargo.toml and Cargo.lock (6e03f65; v0.21.0 pinned c5a1cbf). Before it installs anything:
- On every platform, it downloads only from the app's own release downloads, and checks the file against its published SHA-256: GitHub's per-file digest, or the file's line in the release's
SHA256SUMS.txt. A release with neither is refused before anything is downloaded, and a checksum list that exists but can't be fetched counts as an error, not as "no checksum". - On macOS, it copies the new app out of the DMG and requires a valid Developer ID signature from team
DJ6XS33FX8, nested code included, with thecodesignrequirement shown above. An ad-hoc signature or another developer's fails. The app inside must also report the release's version. - On Windows, the running copy, the installed exe and the new MSI must all carry valid Authenticode signatures from the same publisher, compared by the certificate's subject name. A copy that isn't signed itself doesn't install updates. For the portable zip, the programs in it must pass the same check.
- On Linux, the SHA-256 check is all. The updater doesn't read the
.ascor.sigfiles. That is still true for the Flatpak bundle, which since v0.23.1 can update itself (#13322).
These checks run before anything is replaced. What changed in v0.22.0 is when the update takes effect: on Windows the helper installs the checked MSI or zip when PhotoCraft exits, on macOS and Linux the new version starts once PhotoCraft has exited, and the next start reports whether it worked (#12384). The download page for each system has the details.
The web build and the online editor
The web build, photocraft-web-0.23.1.zip, has no signature of its own. Check it against SHA256SUMS.txt like any other file, and check that list with SHA256SUMS.txt.asc. For v0.23.1 the zip is 16,064,050 bytes with SHA-256 3a498eb517bca6cec89f9c6b1fc6448269a05428c8a3a4637c16817da157f03c.
photocraft.im's online editor runs that zip. The /online page shows which version it runs and the SHA-256 of the release zip it comes from, so you can compare them with the release. The site serves the app's files from the zip unchanged. It leaves out the zip's hosting samples and guide and adds upstream's license notices from the same release tag. One file is served at a second path: the official web zips since v0.17.0 don't start as packaged, because app/photocraft-web.js asks for app/snippets/… while the zip has snippets/ only at its top level (#10017, still open on 12 November 2026). When the browser asks for the app/snippets/ path, the site answers with the zip's own top-level file, byte for byte. Use it here or host it yourself explains this and how to host the build yourself.