Security issue: meta recipes download from untrusted sources

[TheAssassin]

The meta recipes download from repositories (like PPAs or other custom APT sources) bypassing many security mechanisms of APT.
As the AppImages are published and distributed to third parties (talking about https://bintray.com/probono/AppImages/), we should make sure that they are authenticated by using the GPG signature mechanisms built into APT. The binaries should be as trustworthy as possible.
This shouldn't be too difficult to implement. I'd suggest adding a list of keys (or keyrings) for a separate APT keyring to every recipe. These entries could be either

• key IDs that are fetched from a keyserver into the APT keyring using the gpg commandline
• a list of files that we ship in the repository, or
• a URL to download a key from.

Latter is rather insecure, as the file could've been tampered with as easily as the binaries (if they both were on the same server, and an attacker had access to that system), so this is something I would not recommend at all. We might consider adding it as a legacy method though, to be able to use repositories whose signature keys are not published on any keyserver (they're not as rare as you might think).

I'd like to see what you guys think before trying to implement it, so feel free to comment, everyone.

[probonopd]

So you are describing an attack vector where someone takes over the upstream server?
If you check the existing recipes, many use e.g. a single .deb from a GitHub Releases page. There is usually no GPG key available for them.

[TheAssassin]

In comparison to traditional attacks on a user's APT repositories, the attackers' target is the AppImage build system instead of the actual users' systems. The attacks still work. I don't want to make any approximations whether one way is more or less dangerous than the other one, that doesn't really matter in my opinion

An attacker taking control of a repository server is less likely, but one of the scenarios I thought of. A MITM attack is conceivable, since most repositories use the HTTP protocol without SSL, so that the server is not authenticated (less problematic than plain HTTP, but still not super secure).

It is fine for these to download .debs directly (the GitHub servers offer HTTPS, see above), but for all the other packages an AppImage needs, we could easily enable signature checks for example. And whereever a PPA (or any other kind of custom repository) is used, a GPG check should be easy to implement, too.

The point is, we want to use the binaries that distros, vendors etc. (a.k.a. trustworthy sources) provide, and ship those to third parties: the users. But unfortunately, using our AppImages means that the users are not really protected from attacks on the repositories, as we bypass all checks. If they just used apt etc. directly, they are protected from this stuff. If we built all the dependencies from source, it would be another situation either.

I mean, have you ever checked the authenticity of the binaries inside your AppImages or other AppImages you download by hand? I guess not.

[probonopd]

Thanks for the detailed response @TheAssassin. I agree we should do this. PRs welcome.