Signing AppImages

[chrisnharvey]

Quick question. Is there any way to sign AppImages and store the signature inside the AppImage itself, similar to how Mac apps have their code signature info stored inside the application bundle?

[probonopd]

No, the .asc file is external to the AppImage for now. Ideas on how to improve this are welcome.

[chrisnharvey]

Would there be any way to embed this into an AppImage in the future?

I really like the idea of 1 app = 1 file. It would be great if this could remain true and have the signature inside.

[probonopd]

Agree. Ideas on how to improve this are welcome. How does debian do it?

[PHPJosh]

@probonopd debain doesn't store key files with packages either. they are just signed with the packagers keys and the Repos Keys and the keys have to be in the system Keyring with the rest of the trusted keys. almost every Linux distro does it this way. What could be done I guess is have a script or something (the desktopintergration?) go off and ask the users if they want to import the key into the keyring if they trust the Developer/Packager.

[chrisnharvey]

According to this, three files within the deb pacakge (control.tar.gz, data.tar.gz and debian-binary) are signed, then this signature is stored within the deb package.

This is kind-of how I imagined it could work with AppImage's, but we would have to sign every file inside the AppImage, then store the signature inside the AppImage.

I thought of creating an AppImage, signing it, then storing this AppImage and its signature inside another AppImage, but I think this would be a terrible way to achieve this.

Any thoughts?

[PHPJosh]

yes but the actual key file isn't stored in the deb files at all and is why the keys have to be in the systems keyring. the keys are stored on gpg key servers most the time and then are imported from said key servers into the keyring

[PHPJosh]

I think best option would be to store the keys on key servers and then sign the Appimage with the keys and come up with some way to import the keys into the keyring and then have some way to verify the key and make sure the Appimage is from a trusted source

[PHPJosh]

you know I just realized me and you both are developing an OS centered around Appimages.. maybe we should chit chat sometime :)

[chrisnharvey]

Of course, the key would have to be stored in the users keyring, but the signature could be stored in the AppImage somehow, then this signature would be verified against the users keyring to see if its trusted.

[chrisnharvey]

@PHPJosh Funnily enough, I just realised the exact same thing. We should definitely have a chat sometime.

[PHPJosh]

and we are both using Arch as a Base.. think difference is I am forking Arch as I don't want rolling updates in my Project as with rolling updates things can break as since I have been working on my project i have already had some things break. will provide security and bug fix updates and Hardware updates for my project in between major versions.

well as far as talking guess we could use skype TS3 or something.. i have a ts3 server i can bring back online anytime as its been offline for months atm lol

[probonopd]

So the question is: Say we generate a signature for an AppImage. Now we put the signature "into" the AppImage (into a location that was 0x00 padding before). Now, the file is no longer the same and the signature will no longer match the file.

How can we work around that? One idea is that the code that checks the signature first copies out the embedded signature from the AppImage, then overwrites the signature inside the AppImage with the original padding (0x00), verifies the signature (it should now match again!) and finally puts back the signature into the AppImage.

But that is not very elegant, there must be a better way... any ideas?

@Chaz6 suggested piping into gpg. That might work, using a tiny helper in C that replaces a given range of bytes with an equal amount of 0x00s.

http://hick.org/code/skape/papers/elfsign.txt suggests:

       1) Calculate the MD5 checksum of the binary, skipping over
          the signature section of the elf binary.
       2) Extract the signature stored in the signature section
          and determine if the binary was signed and issued
          by a trusted authority.
       3) Decrypt the signed checksum in the binary and compare it
          with your calculated checksum.  If they match the binary
          has not been modified.

So not sign the ELF but a md5 "digest" of it.

[probonopd]

There seem to be ready solutions:

• bsign by @beewoolie ftp://ftp.buici.com/pub/bsign/ (2005, GPG)
• http://hick.org/code/skape/papers/elfsign.txt http://www.hick.org/code/skape/elfsign/ (2004, X.509)
• https://github.com/bartman/elfgpg by @bartman (2009, GPG) using libgpgme and libelf
• signelf by @rhvgoyal https://lkml.org/lkml/2013/1/15/610 (2013, X.509)

[probonopd]

signelf by @rhvgoyal from https://lkml.org/lkml/2013/1/15/610

patch -p0 < ../signelf.diff

sudo apt-get install libssl-dev
make
sudo make install

# Make a key
openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509  -outform DER -out new_signing_key.x509 -keyout new_signing_key.priv

# Sign itself
signelf -i signelf -o signelf.signed -p new_signing_key.priv -c new_signing_key.x509

Seems to have signed the binary BUT when I tried to sign an AppImage (which is an ELF with some filesystem image appended to the end of the ELF) it has truncated the filesystem that is appended to the ELF. So I guess it could now be about time to change the AppImage format to embed the filesystem into the ELF rather than append to it. But that would mean that it wouldn't be possible to put together AppImages easily without using a compiler, e.g., it would break what @develar does in electron-builder.

So maybe we can wrok with @rhvgoyal need to address the above, or roll our own, possibly based on signelf (seems like it didn't go much anywhere on LKML so far but hey, why not use it as inspiration).

[probonopd]

Tor uses GPG for signature verification. The advantage of GPG might be that there is a web of trust that does not come from commercial "Root CAs".

https://www.torproject.org/docs/verifying-signatures.html.en