How to validate AppImage signature? #1237
I have managed to sign an AppImage by following the instructions here:
https://docs.appimage.org/packaging-guide/optional/signatures.html
This page describes how to validate the signature using a tool called "validate". However, no link to this tool is provided and there appears to be no further information to be found on the Internet anywhere?
How does one validate the signature of an AppImage?
As a developer, how do I provide the information to users to confirm validity of AppImages I supply? Do I put a digest on my website or something?
All reactions
My initial assumption was that signing with GPG was synonymous with "code signing" an app in Windows.
It is. The resulting binary package is signed after all, and you can verify the signature. What is missing, as you suggest, in comparison to windows, is a method to ensure only "trustworthy" developers can sign packages. Windows doesn't use PGP but X.509 certificates which they issue themselves for developers. This allows them to build a chain of trust: if we signed their certificate (or someone we trust), we can trust the resulting package. In the AppImage world, we can't easily define which key is trustworthy and which one isn't. Just running validate doesn't mean the key is trustwort...
Replies: 9 comments 5 replies
The idea was that tools like AppImageUpdate check the signature of the new version and compare it with the signature of the old version.
The validate tool, as far as I remember, was not updated/maintained when some changes to the signing process were made, so possibly it's not usable without further development at this time. As far as I know, AppImageUpdate performs at least some basic signature checking.
Overall, the whole idea of carrying signatures inside AppImages did not really gain widespread traction, possibly it is too obscure a feature or we have just not yet found easy enough ways to make use of the concept.
All reactions
Overall, the whole idea of carrying signatures inside AppImages did not really gain widespread traction, possibly it is too obscure a feature or we have just not yet found easy enough ways to make use of the concept.
I guess features relying on signatures will create demand. E.g. before reading this thread, I personally didn't know about AppImageUpdate validating the signatures.
All reactions
The validate tool can at least check that the signature can be read and can be verified (not sure if it is using the embedded key, though). Its main use case is to make sure the signing worked as intended. It was moved to AppImageUpdate's repository, as maintaining more than one code base makes absolutely no sense. See https://github.com/AppImageCommunity/AppImageUpdate/releases/tag/continuous.
PRs to the docs welcome, they have become a little out of date.
Digests work fine, but using validate should work, too. On the other hand, it's really uncommon nowadays (especially due to the fact there's HTTPS everywhere) for files to become corrupted during transfer. Just make sure to clearly communicate with your users that this just means the file has not been corrupted. Digests as well as plain validate cannot make any other guarantees.
AppImageUpdate doesn't just do "basic checking", it ensures cryptographically that an updated AppImage has been signed by the same person which signed the original one. The algorithm guarantees authenticity (assuming the key was handled correctly, of course), something a plain digest check can't do.
All reactions
Thanks guys.
My initial assumption was that signing with GPG was synonymous with "code signing" an app in Windows. This is intended to validate that the package originates from the claimed developer and not some other source. Moreover, in the case of code signing on Windows at least, the idea was that in order to obtain a code signing certificate the developer had to demonstrate to authority that they were a good actor (by handing over company docs and name, address etc.). I was thinking with self generated GPG keys, the developer must put some kind of public key on their site or something instead. In any case, and as a side, I no longer see the value in this whole "trusted authority" thing as I once did.
If the intention with signing AppImages is only to ensure that the package has not been corrupted in transit, then I would guess that a plain old checksum would suffice.
I'm guessing the argument for signing AppImages is no longer seen as a priority.?
All reactions
My initial assumption was that signing with GPG was synonymous with "code signing" an app in Windows.
It is. The resulting binary package is signed after all, and you can verify the signature. What is missing, as you suggest, in comparison to windows, is a method to ensure only "trustworthy" developers can sign packages. Windows doesn't use PGP but X.509 certificates which they issue themselves for developers. This allows them to build a chain of trust: if we signed their certificate (or someone we trust), we can trust the resulting package. In the AppImage world, we can't easily define which key is trustworthy and which one isn't. Just running validate doesn't mean the key is trustworthy. Anyone can generate PGP keys for any random name and email address. That's the major difference to a classic CA-based certificate infrastructure which Microsoft or even the WWW use.
You can put your pubkey on your website, sure. But consider this: if someone manages to, e.g., MITM downloads (very very unlikely nowadays, but you get the point; maybe they just hack your download page) and manipulate downloads, they can just supply their own key. Checking the signature is no better than checking a manipulated hash in that situation. Since the certificates (and keys) in the Windows and macOS world need to be signed by a "trustworthy third party", this attack vector is mitigated to some extent: even if someone managed to hack your website, they'd need a certificate signed by Microsoft or Apple first. And both Microsoft and Apple, like any CA, require personal data from you to submit to them. Law enforcement won't have a lot of problems to find the attacker then.
My point on signing from the beginning has been: as-is, without a way to build such a "chain of trust", it's pretty pointless with PGP keys only. If you can make sure you trust the PGP key, that's great! But just putting it on a website isn't any good. @probonopd initially believed the web of trust (WOT) could help here, but WOT has proven so inefficient and vulnerable to attacks even PGP isn't using that any more, really.
If you consider AppImageUpdate, since it has the old AppImage, it can build a meaningful chain of trust: we trust the current AppImage, so we trust its signing key. If an updated AppImage uses the same(!) key to provide a valid(!) signature, we can trust the update. The fact that we already trust the old AppImage's key is key here (no pun intended).
The only case where I consider downloading a key is better than checking a digest is when you do it once only. We should be able to safely assume that that one moment in time the key is downloaded from the website, it's the correct one. If your users don't just blindly download the key every time over and over again but just once, an attacker can't provide forged files on your website just like this. However, all of this is so much more complex than what we have in the Windows and macOS world, and that alone means users will often get it wrong (e.g., download the key every time) or just won't do it. Unfortunately,
TL;DR: The "I put the pubkey on my website" part isn't really a good idea. It's complex and it's prone to attacks. It's nowhere near comparable to certificate based code signing. And yes, that is unfortunate. The only scenario in which signing with PGP keys makes sense, really, is AppImageUpdate.
I'd love to see more ways how to effectively make use of the signatures, by the way! Please don't hesitate to share your ideas! (But please expect me to discover problems. @probonopd can confirm I like to break his ideas...)
All reactions
Well, I think what a signature can accomplish is to verify that an update has been released by someone who possesses the same private key as whoever had signed the original/earlier version. Realistically, that is what a signature can prove. So, whenever the signature of an update doesn't match the signature of the version being updated, that's at least a cause for suspicion.
The much harder problem - the one I still think some sort of web of trust (maybe one that hasn't been invented yet) - should be able to solve is: who to trust to begin with. E.g., if I as a user trust the authors of, say, Krita and Scribus. And these authors both trust the authors of Inkscape. Then I automatically trust Inkscape as well. Something along those lines. Approximately. (This is just an example. Actually I happen to trust the authors of all mentioned applications.)
All reactions
who to trust to begin with
Publish a list. Make it editable via pull requests. Only merge PRs if authors can prove two things:
- they own the key (let them sign a random challenge in a gist)
- they are maintainers of the app or have some verifiable letter of endorsement by the maintainer
While not all AppImages may be signed by the application authors, the ones who do would get a WoT started.
All reactions
I still fail to see what a "Web of trust" (no matter how it's implemented, the concept is broken already) would add anything to the ecosystem. You download an AppImage from a trusted source. You update it with AppImageUpdate. This builds a transitive chain of trust if you embed the signing pubkey into the previous AppImage and use it to check the new one.
All reactions
-
👍 1
It does not add anything to the update process, neither is this a superior means of verifying the file integrity during download. Instead, the question is whether the AppImage can be trusted during initial installation.
To verify the signature, someone needs to define what makes a key trustworthy. When using a crowdsourced list, the only criterion I can think of is whether the key is owned by the application maintainer.
That said, there are extended ways that achieve further goals like actually verifying that the binary is build from a given source: See SLSA Provenance Attestation, which can be automated easily on GitHub.
All reactions
Hi Assassin,
Thank you for the very detailed explanation. That makes sense.
I have to say that I wasn't familiar with AppImageUpdate, but no doubt I will learn more about it in due course.
As a developer, I find that I am very supportive of AppImage as convenient way to share applications. In fact, I feel very strongly that the software world needs it so that users remain free to choose what software they are able to run.
Thank you
All reactions
You're welcome. To add some more off topic, additional use cases (which AppImage makes relatively simple) are having more than one version of the same app, taking an app with you (e.g., on a USB disk), testing beta releases and a lot more. We should have a use case page in the docs. Please don't hesitate to contribute! https://docs.appimage.org
All reactions
I think we can close this issue, the question has been answered.
All reactions
Guys,
Please don't hesitate to contribute!
Any chance you could enable the "Discussions" page on your Github repository? I'd like to ask questions and share ideas, and perhaps raising them as issues isn't the most appropriate.
Cheers
Andy
All reactions
Will do. I think @probonopd and I already talked about closing down the existing forum in favor of GitHub's discussions feature. I'll enable it for now. If it doesn't work, we can always move to another solution.