How to verify AppImage file with .asc file.
 

Hi.

How can I verify an AppImage file with a .asc file.

For example here: https://bintray.com/probono/AppImages/GIMP#files

There's these files amongst others:
'GIMP-2.9.3.glibc2.15-x86_64.AppImage.asc'
'GIMP-2.9.3.glibc2.15-x86_64.AppImage'

Can a verification be done in a fairly straightforward manner?

Thanks.

Is the .asc file an ASCII text file? If so what does it contain?

I'm wondering if it contains an md5sum or other checksum or hahs of the .AppImage file. If so you could verify by running the commmand (e.g. md5sum) against the .AppImage file and see if it produces the same output.

Hi MW.

The .asc file is here: https://bintray.com/probono/AppImage...4.AppImage.asc

It's a PGP sig.

OK - when I saw .asc my first thought was an ASCII armored (gpg/pgp encyrpted) file as that is what I'm used to seeing on those.

It isn't clear to me how (or even IF) appimage creators are signing. If this particular one is signed running "file GIMP-2.2.9.3.glibc2.15-x86_64.AppImage" should show it as a GPG signed file. If so you should be able to verify it against the signature by running:
gpg --verify GIMP-2.9.3.glibc2.15-x86_64.AppImage.asc GIMP-2.2.9.3.glibc2.15-x86_64.AppImage

What does "file GIMP-2.2.2.9.3.glibc2.15-x86_64.AppImage" output?

What does "gpg GIMP-2.2.2.9.3.glibc2.15-x86_64.AppImage" output?

Does adding "./" in front of the .asc file name in the gpg --verify command line change anything?

And adding "./" changed nothing.

The "file" and "gpg" commands say this AppImage is NOT an encrypted file so the signature unless used by the executable itself has no meaning. Have you already made the AppImage exectuable and tried to run it?

On the GitHub AppImage site there was discussion about adding encryption to files but it didn't really seem to come to a conclusion which is why I earlier said it wasn't clear if they were actually doing it.

I've not used AppImage but the raison d'etre appears to be to create executables that install applications on Linux desktop much the same way as executables are created for Mac and Windows desktops. The idea is to do it this way rather than building an rpm or deb file for the installation. I see various folks have created AppImage files but don't know that I'd want them without knowing the source. (In fact I rarely use 3rd party rpm files - I typically prefer to download the tar.gz, extract, configure and make so I have the actual source code to examine.)

Ok.
So once you download a .appimage file - you cannot look at it's source code?
Since it does not have root privilege, it's possible damage is limited but I guess a rogue file could delete all your personal files or something awful like that.

That's the way I read it but as I said I've not used AppImage myself. I didn't even know it existed until today. (I do a fair amount with gpg but as I said the AppImage file itself is not encrypted).

Yes, all my AppImage files work fine.

I don't know if this will be of any use: https://github.com/AppImage/AppImageUpdate/issues/16

Wouldn't you need the package provider's public key in order to verify the PGP signing?

That's the thread I alluded to in my posts. If you notice it is there as a place holder and doesn't actually come to a conclusion about how best to do things.

Also as noted in my last post the AppImage file itself is NOT encrypted so there is nothing to decrypt or verify as signed to access that file. The makes it seem possible that while the executable itself is not encrypted or signed it may have some routine within itself that checks for a valid signature file. Without seeing the screen output of the actual AppImage exectuable run one couldn't be sure (and maybe not even if one did see the output). If it does have such an internal check since the OP notes he was able to run the AppImage files with no problem so it appears he doesn't need anything else such as a public key.

According to that thread, the internal code to do the checking is currently commented out. In it, they debate the best way of fetching and storing the public key.

Right but that doesn't explain why there is a .asc file shipped with the specific AppImage the OP asked about. It is conceivable someone decided what to do in their own AppImage build. I wasn't saying it definitely was doing such a signature verification - I was speculating on what is possible.

My main point is that the AppImage as a singular file is not encrypted or signed. There is no way to tell what it has built into it without seeing the source code that created the binary. I guess if one were interested they could install the AppImage but NOT the asc file and try to run the AppImage to see what it does.

I suspect it isn't using the .asc file at all but it does make me wonder why the .asc is shipped if that is the case.