Windows
all
Hi,
I was unable to find checksums for binaries provided on github.
Checksums allow to control if binaries on my local disk are binary the same than the remote server ones, i.e. to check that binaries have not been altered due to a network problem or a disk failure while downloading them.
Regards.
@tvataire welcome to the forum.
Previous posts on this forum have revealed that the installers, except for the AppImage, are created using code-signing certificates. If the installer file gets modified due to a network failure or disk problem the install will fail with an error.
I tested this a few years ago by changing just 4 bits (a "nibble" or half a byte) in the entire Windows installer file. The installer threw an error showing:
As the AppImage lacks this a sha512 checksum is provided, as @personalizedrefriger mentioned above.
There is no guarantee that random changes made to an installer will always lead to an error when executing it.
This is the reason why checksums are essential to ensure integrity of any binary file.
The private key generates a digital signature that is appended to the software.
When providing a binary file and its checksum together, although extremely unlikely, there is a probability that inserting random bytes generates a signature corresponding to the new file.
Providing an independent checksum is probably a more secure way to let users check file integrity.
The signature / checksum is generated only once at the time of compilation by the author / publisher using their private key.
I cannot see how it can be claimed that an unsigned checksum in a separate file can more secure. Using the very same argument you raise means that these checksums are at best equally as flawed. This is because it cannot be guaranteed that random changes made to an installer file will not produce a checksum identical to that of the original file. Again, it is extremely improbable, but still theoretically possible.
I cannot see how it can be claimed that an unsigned checksum in a separate file can more secure.
You're right, "more secure" isn't the right term. I meant more reliable.
Have a separate checksum allow to visualize the provided checksum without having to save it on any storage. This can help to detect a storage issue.
I agree that providing a separate checksum doesn't solve all issues. But at least this help to eliminate some of them.
And providing a signature file for checksums can be considered to increase security.
Isn't that exactly what the signed installers do but without needing any extra downloads or tools installed? They checksum the contents, sign it and make it part of the install package. Also in this case it is signed using an external certificate authority who will undertake a certain amount of identity verification (for a price), rather than just creating a GPG key and making the public part available. The only downside of the signed installers is that all this checking of integrity and authenticity is invisible to the user (unless it fails!) who may have experience of using a separate hash and a GPG sig file of that hash.
Yes, the Windows installer is signed with a private key.
No one except Laurent can use this private key (Ignoring the CA's themselves being malicious, the key being stolen, or other externalities).
This key proves that the .exe is both official and untampered. It is in every way equivilent to a signed checksum (The key is used to sign the checksum, in a standard way the OS can understand), aside from the OS is doing these checks automatically.
The only step you'd do manually is like the screenshot above, simply look if it has a signature and verify who it's by. A hacker could sign an arbitrary Joplin binary sure, but they couldn't sign it as Laurent.
Similarly the App Store on MacOS would be signed with a private key (although I'm unsure about the Joplin.dmg download). The iOs and Android versions are signed with a private key. And even the Snap and Flatpak packages are signed with a private key (Less sure about the Flatpak specifics but the deployment is based on similar principles to Git, so the package manager can definitely identify accidental / non-malicious tampering, I'd leave actively malicious adversaries to someone more knowledgable; The snap is just straight up signed with GPG that's handled automatically).
My goal is just to be able to check the integrity of files stored on my disk using independent checksums.
In this context, I just point out that providing signatures for theses checksums could also be a good practice.
This doesn't question the idea of signing the installer itself.
All are useful :
Checksums and their signatures are just additional tools that everyone is free to use or not.
Just to add to what @tvataire said previously, another use of checksums if to verify if the downloaded file is pristine. This is one reason I provide checksums for the Linux packages here.
Cheers
Signing the installer is also implicitly shipping it with a checksum that verifies its integrity. The whole thing is handled by the OS automatically.
If you want to take it manual, then the best approach is likely to download Sigcheck and then use it like this:
Then running the built in Get-FileHash PS function, you can see the two match.
Ultimately, a checksum is provided, it's just provided in a way that the verification is all done automatically. But if you did want to go manual, then this is how.
And this is more secure than the AppImage checksum, because we cannot prove the AppImage checksum is actually endorsed by Laurent in the same way we can with the Authenticode signature on the Windows installer, because the AppImage checksum isn't signed.
To compare against e.g the snap, you can view the checksums and signatures side by side; again proving its myself who actually submitted it.
The AppImage checksum, whilst not insecure or unreliable by itself, is absolutely the least secure validation option Joplin offers, because it's neither automatic nor signed. Most other releases are automatic and signed. To get a similar guarantee, not only would we need a checksum, but then we'd need a PGP signed file confirming the checksum of the checksum, which in short is exactly what Authenticode is doing.
Tl;Dr if you downloaded the Laurent endorsed installer, and a cosmic ray caused a bit flip that changed a single bit in the entire file, then Windows simply wouldn't let you run the installer at all, because it knows it's corrupted instantly. You'd get this:
(And this looks different to the previous error because the older versions weren't signed, so it wasn't the OS throwing the NSIS error earlier in the thread, but it is the OS throwing this error now).
