How to validate AppImage signature?

[kuiperzone]

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?

[probonopd]

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.

[TheAssassin]

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.

[kuiperzone]

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.?

[TheAssassin]

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...)

[kuiperzone]

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

[TheAssassin]

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

[TheAssassin]

I think we can close this issue, the question has been answered.

[kuiperzone]

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

[TheAssassin]

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.