Joplin have a code-signing certificate from a Certificate Authority. This means that when the app is packaged the package contains an embedded cryptographic signature. The OS checks the validity of this signature upon installation. If someone alters the package or it has been corrupted during download the check will fail and the OS will alert the user to that fact. So the checking is automatic and requires no action from the user. Code signing works with MacOS, Windows, Android and IOS. It is only the Linux AppImage that cannot use code signing certificates and so that one has a published SHA512 checksum to enable the user to undertake a manual integrity check.
You are confusing the desktop and Android apps.
As of today the latest desktop (Windows / MacOS / Linux) release version is 3.1.24. The latest desktoppre-release (beta / release candidate) version is 3.2.4 (See Joplin Releases)
As of today the latest Android release version is 3.1.7. The latest Androidpre-release (beta / release candidate) version is 3.2.3 (See Joplin-Android Releases)
People have asked for a hash before, but personally I notice people seem to value the hash too highly.
The hash by itself only confirms the checksum of the package. How can you trust the hash itself? It needs another file that verifies the hash of the hash. But then how do you trust this recursion?
The answer is the key signature mentioned above; the apk contains both the hash of itself, but also a cryptographically signed proof that the hash is correct as per Laurent/Joplin. Android can see this natively and would pick up if the APK you downloaded doesn't come from the same source as the first and respond by refusing to install the package.
Which means as long as you validate the first install you'd be fine; and the ideal way of doing that is with Android's apksigner from Android Studio
Thank you for the explanation. I understand that the OS verifies the integrity of the APK during installation. However, I’d like to ensure that the APK I’m installing comes directly from the official Joplin developers and has not been tampered with.
To do this, I need the SHA-256 fingerprint of the signing certificate (not the hash of the entire APK). This fingerprint allows me to verify that the APK signature matches the one officially provided by Joplin. Tools like AppVerifier on GrapheneOS rely on this information to cross-check the signature and ensure the APK's authenticity.
Would you be able to share the SHA-256 certificate fingerprint? This is a common request among security-focused users who install APKs manually.
Thank you again!
Thank you for the clarification, and I apologize for causing confusion on this point.
That said, I just wanted to note that the version available on the Google Play Store is already listed as 3.1.8, which seems a bit odd. I have no idea where they pulled that version from, as it doesn’t match what’s published on GitHub.
Thanks again for your patience and for helping me understand this better!
Thank you for your response. I appreciate the explanation, but I believe we’re slightly talking past each other here.
I understand the limitations of hashes, as I already mentioned in my previous reply. My focus isn’t on verifying the hash of the APK itself but rather on confirming the SHA-256 fingerprint of the signing certificate. Having this fingerprint allows me to cross-verify that the APK was indeed signed by the official Joplin developers.
You’re absolutely right that apksigner can be used to validate the signature, but that requires access to a terminal (e.g., via Termux on GrapheneOS) and running manual verification commands. While this works, it’s far less convenient compared to simply using a tool like AppVerifier on GrapheneOS, where I can quickly check the signature against a known certificate fingerprint.
Ah, so you mean you want the signing public key's fingerprint to be displayed somewhere; so you can prove that app.joplin from Laurent22 isn't app.joplin from Evil66 (Laurent22)?
I'd imagine that doesn't change too often and it makes sense for what you're needing it for, I'm not sure they are published publically (aside from however Google Play cross-signs them), so you could technically grab them from the current release and compare it over time; but all the better if they were publically available anyway (since they'd be signed and version controlled in Github!)
As a one off quick thing to have public I think it probably makes sense to have somewhere, the downloads page or FAQ would be ideal. The key shouldn't change across revisions so isn't really a "release artifact" per github, but it wouldn't be wrong per se to just have it there.