Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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?
Code:
file GIMP-2.9.3.glibc2.15-x86_64.AppImage
GIMP-2.9.3.glibc2.15-x86_64.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=c271a1d61198e53b90595d8bf0a7d50a57e0a53e, stripped
Code:
gpg GIMP-2.9.3.glibc2.15-x86_64.AppImage
gpg: WARNING: no command supplied. Trying to guess what you mean ...
gpg: no valid OpenPGP data found.
gpg: processing message failed: Unknown system error
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.)
Last edited by MensaWater; 01-10-2018 at 02:59 PM.
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.
So once you download a .appimage file - you cannot look at it's source code?
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).
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.