Build and publish AppImages

[TheAssassin]

I propose to build and ship an AppImage for gef. Building an AppImage would have, among others, these advantages:

• Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally sign your AppImages (inside the file) using gpg2
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions
• Can be listed in the AppImageHub central directory of available AppImages
• Can double as a self-extracting compressed archive with the --appimage-extract parameter

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

AppImages could be built both for releases as well as for the main branch (so-called continuous release scheme). Automating AppImage building is relatively simple and straightforward. You can bundle all tools you need (e.g., a suitable up-to-date GDB version). This way, this project will be a lot easier to set up and use: you will just have to call ./gef-x86_64.AppImage.

The only tricky part here is bundling Python along with gdb. But I could imagine that if you let linuxdeploy-plugin-{python,conda} set up a Python environment, then build gdb against it, it should work. I've done that before.

I've successfully implemented this for pwndbg, see pwndbg/pwndbg#891 for details. I'll file a PR there soon. The AppImages I built so far for pwndbg have been very useful, and make working with the tool a lot easier. There's virtually no setup required any more.

[clark-ja]

To be honest, I don't really see the big advantages of using AppImages.

Going through your mentioned advantages (considering the effort that would be needed to maintain the AppImage):

• GDB and GEF already run on many distributions (including all of the mentioned)
• GDB can be compiled statically and GEF is one file. That makes 2 files instead of one. Not such a big overhead IMO. Also because GEF is just one file (gef.py) setting it up is super simple (either add it do .gdbinit or just use it as command-line argument when you need it or simply add an alias for GDB with GEF like so: alias gef=gdb --nx -ix /path/to/gef.py).
• As mentioned above GDB exists as a statically compiled version so it only needs to be copied over to your machine and GEF never needed to be installed.
• When using the statically compiled GDB also no root is needed to setup.
• Just add a .desktop-file to e.g. /usr/share/applications or ~/.local/share/applications if you want desktop integration
• "binary delta updates" don't really make that much sense in this use case IMO. When there is an update in GEF no "binary diff" is needed because it's python.
• if you want to, releases in GitHub can also be signed and the signature file can be added to the list of files for that release.
• GDB/GEF also works on Live ISOs
• GDB/GEF can also be used from multiple distros installed in parallel (as long as they all have access to the same drive)
• for the last 2 points: also don't really see the advantage there

All in all it seems like a lot of effort for very little to no gain. Currently it is already very easy to use GEF on most (or all?) distros:

• Install GDB with your package mangager or just find a statically compiled version and copy it to your machine
• Run the GEF setup script (at http://gef.blah.cat/sh) or just copy gef.py to your machine and use one of the described steps in point 2 above.

EDIT: I also looked at your pwndbg issue and I agree with their opinion. Also as a sidenote: If you want to use pwndbg parallel to GEF you can just go with the alias solution I described before: e..g alias pwndbg=gdb --nx -ix /path/to/pwndbg/gdbinit.py and alias gef=gdb --nx -ix /path/to/gef.py/ (and if you want to also create two desktop entries for the to launch them directly from your Desktop Environment's launcher.)

If you really want an AppImage I would also suggest that you maintain an unofficial version of it yourself.

[hugsy]

Packaging GEF has always been a controversial issue and I've already explained my thoughts here, but I can re-iterate: additional packaging require more work from us for very little benefit. It also makes things more confusing - which means more complaints and issues on GH for us like "should I install from pip, dpkg, git ..." , "I've installed using xxx and it's not working" etc.) Don't take my word for it, check it out by yourself - you'll notice none of those are maintained by us, and all are dead / unmaintained.

We work hard so that GEF is trivially stupid to install and works out of the box, without mandatory dependencies. There'll always be new distro/packagers etc. and by nature I don't think GEF qualifies to be in any of them.

As I've said before on other discussions, I'm open to change my mind should you present solid arguments.

As this is not an issue per-say, but an open topic I'll move this thread as a Discussion. If enough people are in favor of this, we can re-open it as an issue / PR.

Thanks!