Please provide a distribution-neutral AppImage for Linux

[probonopd]

• I have searched open and closed issues for duplicates

---

Bug description

Currently the application is provided only in .deb format, which makes it hard to use on anything but Debian/dpkg-based systems.

Steps to reproduce

• Run Fedora
• Try to install Signal Desktop

Actual result: Many (undocumented) manual steps need to be executed on the command line
Expected result: As the user, I can download a single file (like an .exe for Windows or a .dmg for macOS) for Linux, and run the application with minimal fuss

Platform info

Operating System: Linux desktop OSes like Fedora, CentOS, or lesser-known ones not based on deb

Recommendation

Providing an AppImage (as has been requested, e.g., here) 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 with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• 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

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

electron-builder, which this project is using, has built-in support for generating AppImages. It is literally as easy as changing

https://github.com/WhisperSystems/Signal-Desktop/blob/475e9020eddc8b224920e45d2ed193be8bce305d/.travis.yml#L12

to

  - ./node_modules/.bin/build --em.environment=$SIGNAL_ENV --config.mac.bundleVersion='$TRAVIS_BUILD_NUMBER' --publish=never --linux=AppImage

i.e., adding --linux=AppImage.

If you have questions, AppImage developers are on #AppImage on irc.freenode.net.

[probonopd]

An example AppImage built on Travis CI is available on https://github.com/probonopd/Signal-Desktop/releases.

[dmhowcroft]

I could settle for an RPM for Fedora/RHEL/CentOS. As for AppImage, there's the question of whether one should use a Snap, a FlatPak, or AppImage for multidistro distribution.

[probonopd]

As for AppImage, there's the question of whether one should use a Snap, a FlatPak, or AppImage for multidistro distribution.

They have different objectives and different principles. As for AppImages, it's ease of use, "one app = one file", needs no special runtimes to be installed before you can run it. And thanks to --appimage-extract, it can double as a self-extracting compressed archive, too.

[philipzae]

I could settle for an RPM for Fedora/RHEL/CentOS. As for AppImage, there's the question of whether one should use a Snap, a FlatPak, or AppImage for multidistro distribution.

You can find a comparison chart of appimage, snap and flatpak here
https://github.com/AppImage/AppImageKit/wiki/Similar-projects#general

[stratacast]

I want to rant about this each time I see I don't have signal for desktop anymore, but then I remember you're a small team and ISO a desktop dev. So, best of luck :) many many many many many of us would love something independent of Ubuntu/Debian. I also know a lot of BSD people would like this too, so perhaps even having something that is just easy to build from source would be great. I wouldn't mind building my desktop app for *Linux and *BSD (I think)

[probonopd]

electron-builder can build AppImages.

[willwh]

I'd also like to see something other than a .deb, we mostly run Fedora desktops, an rpm or an AppImage as suggested, would be great.

[bcm0]

Does anyone have a working script to build the appimage locally?

[dmhowcroft]

Note that you can install it on Fedora through dl.flathub.com. I'm not sure what settings you need to change, if any, to get it to appear in the GUI software installer (Software), but it shows up there for me when I search.

Sorry I don't have an AppImage build recipe for you, adnion.

[bcm0]

Thank you for your reply.
I found it:
https://flathub.org/apps/details/org.signal.Signal
But sadly it's flatpak package format only.

[probonopd]

Looking at the many thumbs-ups in this ticket, it seems that there is considerable demand for an AppImage. @liliakai, @scottnonnenberg what do you think? Would you entertain a PR?

[thenktor]

As Slackware user I'd like to vote for an official Appimage, too. Even Wire has one.

[stratacast]

I just think they need to get off the "cross platform" base known as Electron. They tout security, yet they use the most bloated method possible to provide "cross platform" support. Really what they did was limit their userbase to Windows/Linux/some Linux and knocked out the rest who had access to a chromium-based browser. If this was an intermediary solution I think it would be reasonable and fair as they built something in, say, C++ or whatever so it could be easily cross-compiled even on BSD operating systems.

[kemsar]

My PR for AppImage support was declined, so I'd like to bump this conversation to find out what @scottnonnenberg-signal feedback is and what needs to happen to get this approved. I've been using my AppImage build for months on Fedora but just switched to Ubuntu so don't really need it anymore. But when I ran across this issue, I figured it might help out others.

So, back to the question: what needs to happen to get AppImage approved?

[vphantom]

AppImage is the only format where users can simply download the file and run it, regardless of Linux distribution. No daemons or other special requirements for users, unlike Snap and FlatPak. If it's already supported by the build system Signal Desktop is using, then it can only benefit the community to enable it. A single-file executable is the simplest way by far for a user to test the software; no fussing with Apt.

I find it odd that the PR was rejected outright for being a "new platform to support" given that an AppImage is literally just a fancy archive format. Because Signal Desktop is not compiled, there can't be a "static build" so this would be the next best thing.

I hope Signal will reconsider, given that it seemingly would involve no additional work.

[bcm0]

Great work @kevinsarsen #3055
I really hope @scottnonnenberg-signal has some time to decide about this.

[probonopd]

https://www.andreafortuna.org/2019/03/27/how-to-build-signal-desktop-on-linux/ describes how to build a Signal AppImage.

A test one is available from https://cdn.andreafortuna.org/Signal-Desktop-Beta/.

[skeet70]

Has their been any communication somewhere on why this isn't being accepted/done? I'm setting up an Arch laptop for work and while there exists an AUR package for signal, it would've been much nicer to find a .AppImage from Signal officially a la Bitwarden.

[codewing]

Since there is no web client signal becomes impossible to use on devices where you're not able to install the software as well (e.g, my home university). Running an AppImage is allowed there and thus I support this ticket!

[ghost]

so since the fedora snap version is not working for over a month. I would like to see a appimage version also.

[shoogle]

+1. AppImage is basically the Linux equivalent of .app bundles on macOS:

• Totally portable with no external depenencies
• Built and distributed in-house (i.e. from https://signal.org/download/)
  • can offer regular updates without waiting for distributions or maintainers

AppImage enables you to offer a single Linux download that will work on all distros out-of-the-box (unlike Flatpaks or Snaps which rely on users having access to a particular appstore or package manager).

[ctrlcctrlv]

I downloaded and ran ./Signal 1.25.0-beta.4.AppImage

It's not even that old, but it refuses to work. Lovely. 🙄

To build according to the AUR the LTS nodejs is needed, but I need the latest nodejs for something else, and they conflict. So, yeah, guess I'm not using Signal for now.

[probonopd]

https://www.andreafortuna.org/2019/03/27/how-to-build-signal-desktop-on-linux/

[ctrlcctrlv]

Is that for me? I'm no longer interested in Signal due to what I wrote above.

[dmhowcroft]

@ctrlcctrlv, where did you download that from? From andreafortuna.org? If so, that's not an official distribution channel and I don't know why you're posting about it in this thread as though it is the developers' fault.

@scottnonnenberg-signal: as others have asked over the past two years, what needs to happen to have an AppImage build process accepted? And if it's not being actively considered, can you please clearly articulate why and close this issue so we stop holding our breath?

[ctrlcctrlv]

It is the developers' fault for so quickly deprecating releases, regardless of the distribution channel. As stated, I have no good way to build it myself, and scarce little time to do so.

@probonopd donated their time to the project and made an AppImage available even though none existed officially. This was a selfless, noble act.

1.25.0 was released on May 31. I tried it on October 29, around five months later.

@probonopd's work was squandered because apparently releases that are five months old are so old that they must be bricked remotely by the server. 🙄

But yes, please continue to tell me about how it's not the developers' fault that they squandered the community's efforts to fix a problem they have no interest in even addressing.

Meanwhile I'll not bother using this app.

[maverick74]

I believe an AppImage should be THE official Linux package for distributing Signal!!!
It would allow me to have it anywhere.

[mdedonno1337]

Still maintaining a build of the AppImage here, but since version 5.36.0, the resulting appimage shows the following error :

$ ./Signal-5.36.0.AppImage
Squashfs image uses (null) compression, this version supports only xz, zlib.

Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage
if you run it with the --appimage-extract option.
See https://github.com/AppImage/AppImageKit/wiki/FUSE
for more information
open dir error: No such file or directory

Any idea ?
ping @probonopd

PS: The compilation script is the following:

image: node:16.13.0

variables:
  GIT_SUBMODULE_STRATEGY: recursive

stages:
  - build

build:
  stage: build
  script:
    - unset $(compgen -v | grep "CI")
    - apt-get update
    - apt-get install -y jq git-lfs
    - cd Signal-Desktop
    - cat package.json | jq '.build.linux += {target:["AppImage"]}' > with_appimage_package.json
    - mv with_appimage_package.json package.json
    - yarn install
    - yarn build-release
    - ls -la ./release
    - pwd

  artifacts:
    paths:
      - ./Signal-Desktop/release/*.AppImage
    expire_in: 1 week

[probonopd]

That error doesn't ring a bell with me. Which tools are you using to produce the AppImage?

[kalatabe]

I created this Dockerfile which is functionally equivalent to the build script posted by @mdedonno1337 above. It creates the AppImage in /opt/project/release/Signal-5.41.0.AppImage, when I copy it out of a running container and attempt to run it, I get the same error:

Squashfs image uses (null) compression, this version supports only xz, zlib.

Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage
if you run it with the --appimage-extract option.
See https://github.com/AppImage/AppImageKit/wiki/FUSE
for more information
open dir error: No such file or directory

I'm trying to start it on Fedora 35 if that matters.

PS: During building, the following error appears in the logs. I'm not sure if it could be the cause.

$ electron-builder install-app-deps
  • electron-builder  version=23.0.1
  • loaded configuration  file=package.json ("build" field)
  • rebuilding native dependencies  [email protected], [email protected], [email protected], [email protected], [email protected] platform=linux arch=x64
  • install prebuilt binary  name=sharp version=0.29.3 platform=linux arch=x64 napi=
  • install prebuilt binary  name=mac-screen-capture-permissions version=2.0.0 platform=linux arch=x64 napi=
  • build native dependency from sources  name=mac-screen-capture-permissions
                                          version=2.0.0
                                          platform=linux
                                          arch=x64
                                          napi=
                                          reason=prebuild-install failed with error (run with env DEBUG=electron-builder to get more information)
                                          error=/opt/project/node_modules/node-abi/index.js:30
      throw new Error('Could not detect abi for version ' + target + ' and runtime ' + runtime + '.  Updating "node-abi" might help solve this issue if it is a new release of ' + runtime)
      ^

    Error: Could not detect abi for version 17.3.1 and runtime electron.  Updating "node-abi" might help solve this issue if it is a new release of electron
        at getAbi (/opt/project/node_modules/node-abi/index.js:30:9)
        at module.exports (/opt/project/node_modules/prebuild-install/rc.js:53:57)
        at Object.<anonymous> (/opt/project/node_modules/prebuild-install/bin.js:8:25)
        at Module._compile (node:internal/modules/cjs/loader:1101:14)
        at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
        at Module.load (node:internal/modules/cjs/loader:981:32)
        at Function.Module._load (node:internal/modules/cjs/loader:822:12)
        at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
        at node:internal/main/run_main_module:17:47

[ctrlcctrlv]

Where are we in regards to the AppImage happening, is it just that there is nobody to keep pushing it forward or what?

No, it's Signal Messenger LLC incompetence, as demonstrated by this thread and the fact that thousands of open source projects manage this with no issues every single day. They don't care about actual security, @sunknudsen points to exactly why this should have existed back when I first commented…oh, 2019 or so:

Being able to run Signal on Tails would be amazing! +1 for .AppImage release.

This could be a gold-standard application, instead it is a joke.

---

I might be wrong with this but I don't think it is possible to automatically update AppImages? Given the frequency of updates on the deb version (around 150 MB every three weeks) I don't think it would be possible unfortunately... Otherwise it would be really awesome.

If you want to force users to update the AppImage file, then brick the damn thing. They had no problem bricking @probonopd's build in 2019. And likely are continuously bricking the existing AppImages, so it already exists. You could of course make the update process nicer than a brick, you can even rewrite the AppImage you're running from in-place, but that requires work.

---

If I am coming off short it is just because this company is rich—they have far more resources than any project I contribute to, including the largest ones. Yet all of them have AppImages, and I continue to get notifications on this issue for the last three years because Signal LLC cannot do what I and thousands of other Linux developers have done since @probonopd released his amazing AppImages project. So whose fault could it possibly be, if not Signal LLC's?

[BinaryGenius]

@ctrlcctrlv I'm sorry LLC? Are they not a non profit as per their own website?

[virtualdxs]

The Signal Technology Foundation is a 501(c)(3). It owns the subsidiary Signal Messenger LLC, which is responsible for Signal development.

[BinaryGenius]

Okay so Signal Technology Foundation is a non profit then it's subsidiary inherits that so it is also a non profit and they make money from donations. But I heard they are rich how can that be are the donations really that substantial? Are companies and non profits the same thing?

[dmhowcroft]

That is pretty off-topic and something you can find out more about with Google and Wikipedia.

The underlying problem remains that after years of watching this issue, the developers still don't want to give us an official AppImage.

[BinaryGenius]

I feel like that's a lazy response but regardless it is off topic like you said. I have to ask though because I'm seeing this in the repo, do the devs really lock out other appimages for signal because that sounds pretty bananas to me.

[ctrlcctrlv]

They do.

[BinaryGenius]

Wow, is there anything we can do aside from just using another app. There must be tons of people who have pushed mountains keeping their families on signal just to say now that everyone needs to use session or element.

[fancsali]

Well, reading through this thread is troubling to say the least.

If you're not on Debian, you're outta luck Then you can go around, and try to find a Flatpak/Snap package or AppImage, that someone, somewhere build. That's a big no-no in security.

Can we at least have an INSTALL file documenting how to compile it yourself, while this is settled (if ever)?

[rk9qn3j]

Yep, long thread indeed.. It's sad to still see that such a simple thing is so hard to implement. Linux must become easier to allow further adoption. +1 for .AppImage.

[stickyburn]

+1 for appImage though million thanks to awesome AUR devs!

[affinityv]

My solution, create a Ubuntu VM, copy .config/Signal directory; connect with "ssh -X", open Signal Desktop (once all the right things were installed int he Ubuntu instance). Official app that will update, no risk. My ssh is secured with a key as well and it most certainly is not available form the Internet, nor with ordinary password login.

[ChildishGiant]

This is a matter of making a github action (15 mins work maybe). If it's not been done in the past 6 years, I doubt they mind it being a while longer so we need to turn to community (flatpak, aur etc)

[leighss]

+1 for Appimage

[kalatabe]

Dockerfile:

FROM ubuntu:22.04
RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get full-upgrade -yqq
RUN DEBIAN_FRONTEND=noninteractive apt-get install -yqq wget gpg x11-common x11-utils x11-xserver-utils xorg xinit bash xdg-utils
RUN wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg
RUN cat signal-desktop-keyring.gpg | tee /usr/share/keyrings/signal-desktop-keyring.gpg > /dev/null
RUN echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg] https://updates.signal.org/desktop/apt xenial main' |\
      tee /etc/apt/sources.list.d/signal-xenial.list
RUN apt-get -yqq update && DEBIAN_FRONTEND=noninteractive apt-get install -yqq signal-desktop
RUN apt-get clean
COPY entrypoint.sh /entrypoint.sh
RUN useradd user
RUN chmod +x /entrypoint.sh
RUN chown user:user /entrypoint.sh
RUN chown user:user /home/user -R
USER user
ENTRYPOINT ["/entrypoint.sh"]

entrypoint.sh:

#!/usr/bin/env bash
signal-desktop --no-sandbox

Launcher script:

#!/usr/bin/env bash

docker run --net=host \
--rm \
-e DISPLAY=$DISPLAY \
-v /tmp/.X11-unix:/tmp/.X11-unix \
-v $HOME/.Xauthority:/home/user/.Xauthority \
-v $HOME/.config/Signal:/home/user/.config/Signal \
-v /run/dbus:/run/dbus \
-i \
-t \
signal 

---

1. Build Docker image: docker build -t signal .
2. Put launcher script somewhere in your $PATH
3. Start with signal from terminal or via your favorite app launcher

The above is for X11, no idea how to make it work on Wayland.

[secretmango]

please use a Flatpak and not appimage.

• deduplication of libraries (and Electron is huge)
• security advantages (you can still enable filesystem=home:ro to allow pasting stuff)
• metadata through appstream

and there already is one, you just need to adopt it.

[Samueru-sama]

* deduplication of libraries (and Electron is huge)

flatpak is huge on itself since apps will pull different runtimes, and for example the gnome-runtime on its own is 2 GIB, which all the 30+ appimages that I have don't add up to the size of that single runtime, let alone that doesn't count the flatpak apps themselves.

* security advantages (you can still enable `filesystem=home:ro` to allow pasting stuff)

You can also sandbox appimages...

* metadata through appstream

?

---

To the signal devs If you don't want to provide an appimage, at least provide some "universal" binary like telegram does, I think an appimage is better, but at least that's better than having to install flatpak for this single application.

Note I'm not a signal user, came here because of this issue we had at AM and I find it sad that somebody that's new is trying to make an appimage of signal because the devs can't provide one, if signal is just an electron app that should be easy to make an appimage of with electron builder iirc.

[fancsali]

I'd be happy if it'd be reasonably straightforward to compile Signal myself... ;)

[Samueru-sama]

I'd be happy if it'd be reasonably straightforward to compile Signal myself... ;)

There is already two unofficial appimages:

https://github.com/Twig6943/Signal-AppImage

https://huggingface.co/datasets/Azathothas/Toolpacks-Extras/blob/main/x86_64-Linux/signal-desktop.NixAppImage

Note these methods use containers, essentially shipping an entire distro in the AppImage and that's why they are +250 MiB.

If it is made "the usual way", that is getting the electron binary + bundle the libraries it needs, it would ends up being about ~110 MiB which is the size of the electron appimages that I've seen.

[karo-solutions]

Here is my simple and easy to follow guide on how to build the Signal-Desktop AppImage from the official source code: https://github.com/karo-solutions/Signal-Desktop-AppImage

The only prerequisite is docker or podman and the version of Signal can be specified.
The latest stable (v7.29.0) AppImage has about 160 MB and can be found in Releases

Update:
I added a GitHub Action that checks for a new Signal Version weekly, rebuilds the AppImage on demand and uploads it to Releases .
I also re-pack the AppImage with a static appimage runtime and use zstd compression, which makes it "only" 144MiB. (see karo-solutions/Signal-Desktop-AppImage#1)

[Samueru-sama]

There is now appimage releases at https://github.com/karo-solutions/Signal-Desktop-AppImage that use the static appimage runtime (no libfuse2 dependency) and also have working delta updates with appimageupdatetool.